Feb
28
2022
--

Talking Drupal #336 – Discover Drupal

Today we are talking about Discover Drupal with Angie Sabin.

www.talkingDrupal.com/336

Topics

  • Drupal 10.0.0-alpha2 was tagged
  • Describe Discover Drupal
  • Importance of Discover Drupal
  • Roles in DD
    • Trainee
    • Mentor
    • Supporter
  • Mentor’s responsibilities
  • Time commitment
    • Mentor
    • Trainee
  • Mentor application closed
  • North America only and plans to expand
  • Other ways to support the program
  • Number of trainees
  • Plans to join with EDU

Resources

Guests

Angie Sabin – https://www.drupal.org/u/angiesabin

Hosts

Nic Laflin – www.nLighteneddevelopment.com @nicxvan John Picozzi – www.epam.com @johnpicozzi Martin Anderson-Clutz – @mandclu

MOTW

Search Overrides

  • What the module does
    • Allows editors to specify “featured results” for specific queries, using a capability built into modern versions of Apache Solr
  • What versions are available
    • 2.0.3, works with Drupal 8 and 9
  • What you like about the module and how you use it
    • It provides an admin page for creating and managing overrides, but you can also create overrides and exclusions for a node while editing it
  • What you like about the module and how you use it
    • By default works with nodes, but can be configured to pull from a search
  • Dependencies to thinks about
    • Requires using Apache Solr for search
Feb
28
2022
--

Backup/Restore Performance Conclusion: mysqldump vs MySQL Shell Utilities vs mydumper vs mysqlpump vs XtraBackup

MySQL Restore Backup Comparison

MySQL Restore Backup ComparisonA little bit ago, I released a blog post comparing the backup performance of different MySQL tools such as mysqldump, the MySQL Shell feature called Instance Dump, mysqlpump, mydumper, and Percona XtraBackup. You can find the first analysis here:

Backup Performance Comparison: mysqldump vs. MySQL Shell Utilities vs. mydumper vs. mysqlpump vs. XtraBackup

However, we know the backups are just the first part of the story. What about the restore time? And which tool performs better for the complete operation (backup+restore)?

Let’s see the results and the conclusion in the following sections.

Benchmark Results

I ran the benchmark on an m5dn.8xlarge instance, with 128GB RAM, 32 vCPU, and two io1 disks of 600GB (one for backup and the other one for MySQL data) with 5000 provisioned IOPS. The MySQL version was 8.0.26 and configured with 89Gb of the buffer pool, 20Gb of redo log, and a sample database of 96 GB (more details below).

When we sum the backup time and the restore time, we can observe the results in the chart below:

MySQL Backup and Restore

And if we analyze the chart without mysqldump to have a better idea of how the other tools performed:


The backup size created by each tool:

MySQL Backup Size

Note that the backup size of XtraBackup (without compression) is the size of the datadir without the binary logs. Next, we can see the backup time:

Time to execute MySQL backup

And the restore time:

Time to restore MySQL

Analyzing The Results

When we sum backup and restore times, we observe that the fastest tool is Percona XtraBackup. The main point of XtraBackup is not even the speed but its capacity to perform PITR backups. Also, the tool supports compression and encryption.

We can also observe that mydumper/myloader and MySQL Shell utilities produce good results in both phases. The difference from Xtrabackup is that both tools perform logical backups, which means that these tools connect to MySQL and extract the data to dump files. Because they have to extract data from MySQL, these tools are more sensitive for the MySQL configuration and backup/restore parametrization. For example, MyDumper/MyLoader has some extra options that can improve the backup and restore performance, such as --rows, --chunk-filesize, and --innodb-optimize-keys.

Note that  XtraBackup, MyDumper, and mysqldump support stream restore, reducing overall timing to perform the backup and restore operation. 

The tool that has the most inconsistent behavior is mysqlpump where the tool can make speedy backups, but the restore performance is terrible since it is single-threaded the same way as mysqldump. 

Based on the tests, we can observe that compression, TLS, socket, or TCP/IP do not significantly impact the time needed to perform the whole operation. Because there is no significant impact, tools that can perform compression and use TLS like MySQL Shell, mydumper/myloader, and XtraBackup have a good advantage since their backups are safer and use less disk space (less disk space = fewer costs). The trade-off between the features of these tools and the time spent to backup and restore the database is something that all DBAs should evaluate.

And to answer some questions/comments about this topic:

The difference you see between MySQL Shell and mydumper can be explained by the use of SSL in one and clear transfer in the other. Encryption has a cost, unfortunately. 

A: Indeed, SSL has a cost. However, when we put the security benefits of the SSL and consider the whole process, it is a small cost (in the same way as compression).

Does XtraBackup support ZSTD? 

A: At this moment, no. However, there is a feature request for this (you can follow the JIRA ticket to receive updates about it):

https://jira.percona.com/browse/PXB-2669

Is there any difference substituting mysqldump | gzip with a different compression tool?

A: The difference is neglectable piping with gzip or sending the uncompressed dump to the disk. The mysqldump tool is the most inefficient option due to its single-thread nature, severely impacting performance. Because of its single-thread nature, the tool cannot extract maximum performance from hardware resources (in particular I/O).

How is the performance impact on MySQL when running the backups?

A: Unfortunately, I did not measure this. Based on my experience, there is a dedicated replica server for backup most of the time. If the MySQL community is interested in this test, I can write another post about this (leave in the comments your opinion). 

It is possible to squeeze more juice from MySQL in the restore phase. We can take some actions like disabling the binary log and making asynchronous writes. You can check the advice (pros and cons) in these two blog posts:

https://www.percona.com/blog/2020/05/14/tuning-mysql-innodb-flushing-for-a-write-intensive-workload/

https://www.percona.com/blog/2014/05/23/improve-innodb-performance-write-bound-loads/

To conclude, this blog post is intended to give an overall idea of how these tools perform. I tried to stick with the default options of each tool (except the number of threads) to keep the test as fair as possible. Also, time is not the only thing that companies consider to adopt a backup method (security, encryption, and data protection are very important). In my daily tasks, I use mydumper/myloader and XtraBackup because I’m more familiar with the commands, and I have used them for a long time. However, I would advise keeping an eye on the MySQL Shell utilities since it is becoming a fascinating tool to perform many tasks (backup and restore have excellent results).

Hardware and Software Specs

These are the specs of the benchmark:

  • 32 CPUs
  • 128GB Memory
  • 2x io1 disks 600 GB with 5000 IOPS each
  • Centos 7.9
  • MySQL 8.0.26
  • MySQL shell 8.0.26
  • mydumper 0.11.5 – gzip
  • mydumper 0.11.5 – zstd
  • Xtrabackup 8.0.26

Useful Resources

Finally, you can reach us through the social networks, our forum, or access our material using the links presented below:

Feb
25
2022
--

Logical Replication/Decoding Improvements in PostgreSQL 13 and 14

Logical Replication/Decoding Improvements in PostgreSQL

I recently blogged about how Patroni Addresses the Problem of the Logical Replication Slot Failover in a PostgreSQL Cluster. In fact, nothing else was hurting a logical replication as much as this problem. Even while I am writing this post, I could see customers/users who don’t have Patroni struggling to address this. Thanks to the Patroni community for addressing this problem in the most magnificent way: No patch to PostgreSQL, no Extensions required! Completely non-invasive solution.

As the biggest road-block/deterrent is gone, we expect more and more users to start looking into OR re-considering the logical replication, especially those who discarded it due to practical difficulties. I want to let them know that there are a lot more exciting new features related to logical replication/decoding in new versions like PostgreSQL 13 and 14.

Before getting into new features, let us look at what else was hurting in logical replication in older PostgreSQL versions.

Memory Usage and Disk Usage

PostgreSQL used to keep only 4096 changes (max_changes_in_memory) for each transaction in memory. If there is a very lengthy transaction, the rest of the changes will be spilled to disk as spill files. This has two important implications. First, if each change is really big and if there are sub-transactions, the memory consumption can easily run into several GBs. This can even affect the host machine’s stability and the chance of OOM kicks-in. On the other hand, if the changes are very small and if there are too many small changes, it will be spilled to disk if the transaction is lengthy, causing IO overheads.

Massive Replication Delays and CPU Load

It was almost a regular complaint from many users that they keep seeing huge replication lags. A closer inspection shows the WAL Sender is consuming a lot of CPU. Single-core saturation was the commonly reported case. Many times, a further closer investigation reveals that there was a long-running transaction or a bulk data loading and causing the generation of spill files. The system is busy going through the spill files and preparing the commit order, which needs to be sent to a logical replica

Again, we witnessed a few cases where users opted for logical replication to reduce the load on the primary. But the complexity (CPU and IO usage) during the logical decoding by the WAL sender wiped out all potential gains.

These problems were not something unknown to the PostgreSQL community. In fact, the discussions started around the same time PostgreSQL 10 was released about the problems and their fixes. The good news is all these are addressed in the recent development.

I would like to express my gratitude from user communities to those who contributed their time and effort in developing these wonderful solutions. Namely, Tomas Vondra, Amit Kapila, Dilip Kumar, Masahiko Sawada, Vignesh C, and there are many more who gave very valuable input like Peter Eisentraut, Masahiko Sawada, and Andres Freund.

Improvements in PostgreSQL 13

The problem of memory and disk usage is basically addressed in PostgreSQL 13. Now the max_changes_in_memory (4096) is not used while adding changes. Instead, total memory usage for all transactions together and memory usage for individual transactions are tracked. A new parameter logical_decoding_work_mem is introduced. The buffer will be spilled to disk only if this limit is exceeded and only the largest transaction which consumes the highest amount of memory will be the victim to be spilled to disk. This is smarter and reduces unwanted disk spills also.

Reference: ReorderBufferCheckMemoryLimit (src/backend/replication/logical/reorderbuffer.c)

Improvements in PostgreSQL 14

Spilling to disk when logical_decoding_work_mem is full is one idea. But what about transmitting the changes directly to subscribers instead of spilling to disk. This is the major change/improvement in PostgreSQL 14. But that is not that easy as say because we are dealing with ongoing transactions. Overall logic and feature for logical replication had to undergo huge changes.  But yes, PostgreSQL 14 introduces the option to stream the

reorderbuffer

to the subscriber rather than spill to the disk first. Obviously, this new feature to stream the ongoing transaction required the improvement of the replication protocol. New message formats like “Stream Start”, “Stream Stop”, “Stream Commit” and “Stream Abort” etc are added to the replication protocol. Please refer to the PostgreSQL documentation: https://www.postgresql.org/docs/14/protocol-logicalrep-message-formats.html for more details.

The corresponding changes are also required on the output plugin interface also. This is also an improvement in PG 14. Please refer the commit 45fdc9738b for more details and refer to the PostgreSQL doc.

The streaming is considered when the logical_decoding_work_mem is exceeded. This doesn’t mean that the buffer is never spilled to the disk. Spilling to disk remains the option if streaming is not possible. This happens if the information currently available is not sufficient to decode.

The commit 7259736a6e5b7c7588fff9578370736a6648acbb summarizes the big improvement.

Instead of serializing the transaction to disk after reaching the logical_decoding_work_mem limit in memory, we consume the changes we have in memory and invoke stream API methods added by commit 45fdc9738b. However, sometimes if we have incomplete toast or speculative insert we spill to the disk because we can’t generate the complete tuple and stream. And, as soon as we get the complete tuple we stream the transaction including the serialized changes.

We can do this incremental processing thanks to having assignments (associating subxact with toplevel xacts) in WAL right away, and thanks to logging the invalidation messages at each command end. These features are added by commits 0bead9af48 and c55040ccd0 respectively.

Now that we can stream in-progress transactions, the concurrent aborts may cause failures when the output plugin consults catalogs (both system and user-defined). We handle such failures by returning ERRCODE_TRANSACTION_ROLLBACK sqlerrcode from system table scan APIs to the backend or WALSender decoding a specific uncommitted transaction. The decoding logic on the receipt of such a sqlerrcode aborts the decoding of the current transaction and continue with the decoding of other transactions.

How to Setup

The necessary features are available only from PostgreSQL 14. And client needs to initiate a replication connection with “streaming” on. To facilitate this, the CREATE SUBSCRIPTION takes a new input parameter “streaming”, which is off by default. Following is an example:

CREATE SUBSCRIPTION sub1 CONNECTION 'host=pg0 port=5432 dbname=postgres user=postgres password=xxxx' PUBLICATION tap_pub WITH (streaming = on);

Please make a note of the new parameter streaming =on which specifies whether streaming of in-progress transactions should be enabled for this subscription.

Alternatively, an existing subscription can be modified to enable streaming.

ALTER SUBSCRIPTION sub1 SET(STREAMING = ON)

Monitoring Improvements

There are two major improvements in terms of monitoring.

Monitoring the Initial Data Copy

PostgreSQL 14 allows users to monitor the progress of the COPY command using a new monitoring view

pg_stat_progress_copy

. This is a great value addition when someone is setting up the logical replication. Please refer to the documentation for more details.

The following is the sample output of:

select * from pg_stat_progress_copy ;

  from the PUBLISHER side using psql’s

\watch

Wed 23 Feb 2022 07:01:46 AM UTC (every 1s)

 pid  | datid | datname  | relid | command | type | bytes_processed | bytes_total | tuples_processed | tuples_excluded 
------+-------+----------+-------+---------+------+-----------------+-------------+------------------+-----------------
 2034 | 16401 | postgres | 16390 | COPY TO | PIPE |       932960052 |           0 |          9540522 |               0
(1 row)

                                      Wed 23 Feb 2022 07:01:47 AM UTC (every 1s)

 pid  | datid | datname  | relid | command | type | bytes_processed | bytes_total | tuples_processed | tuples_excluded 
------+-------+----------+-------+---------+------+-----------------+-------------+------------------+-----------------
 2034 | 16401 | postgres | 16390 | COPY TO | PIPE |       976060287 |           0 |          9979509 |               0
(1 row)

Since we know how many tuples are there in the table, we don’t have any difficulty in understanding how far it is progressed.

Similar monitoring is possible from the SUBSCRIBER side also:

Wed 23 Feb 2022 07:01:46 AM UTC (every 1s)

 pid  | datid | datname  | relid |  command  |   type   | bytes_processed | bytes_total | tuples_processed | tuples_excluded 
------+-------+----------+-------+-----------+----------+-----------------+-------------+------------------+-----------------
 1204 | 14486 | postgres | 16385 | COPY FROM | CALLBACK |       912168274 |           0 |          9328360 |               0
(1 row)

                                         Wed 23 Feb 2022 07:01:47 AM UTC (every 1s)

 pid  | datid | datname  | relid |  command  |   type   | bytes_processed | bytes_total | tuples_processed | tuples_excluded 
------+-------+----------+-------+-----------+----------+-----------------+-------------+------------------+-----------------
 1204 | 14486 | postgres | 16385 | COPY FROM | CALLBACK |       948074690 |           0 |          9694752 |               0
(1 row)

Monitoring the Logical Replication

Monitoring logical replication is possible through the new view available from PostgreSQL 14: pg_stat_replication_slots on the PUBLISHER side. (Name is similar to pg_replication_slots ). But this view is a great improvement.

This is of great use even if we are not using the new streaming feature because there is a higher chance of generating spill files.

postgres=# select * from pg_stat_replication_slots ;
 slot_name | spill_txns | spill_count | spill_bytes | stream_txns | stream_count | stream_bytes | total_txns | total_bytes | stats_reset 
-----------+------------+-------------+-------------+-------------+--------------+--------------+------------+-------------+-------------
 sub       |          1 |          34 |  2250000000 |           0 |            0 |            0 |       2701 |     1766040 | 
(1 row)

As we can see in the above case, there was a single bulky transaction, which caused a lot of spill files.

Statistics related to a particular slot can be reset using function 

pg_stat_reset_replication_slot();

postgres=# select pg_stat_reset_replication_slot('sub');
 pg_stat_reset_replication_slot 
--------------------------------
 (1 row)

postgres=# select * from pg_stat_replication_slots ;
 slot_name | spill_txns | spill_count | spill_bytes | stream_txns | stream_count | stream_bytes | total_txns | total_bytes |          stats_reset          
-----------+------------+-------------+-------------+-------------+--------------+--------------+------------+-------------+-------------------------------
 sub       |          0 |           0 |           0 |           0 |            0 |            0 |          0 |           0 | 2022-02-23 15:39:08.472519+00
(1 row)

With the streaming enabled, we can get details of streaming of ongoing transactions:

Wed 23 Feb 2022 03:58:53 PM UTC (every 2s)

 slot_name | spill_txns | spill_count | spill_bytes | stream_txns | stream_count | stream_bytes | total_txns | total_bytes |         stats_reset         
-----------+------------+-------------+-------------+-------------+--------------+--------------+------------+-------------+-----------------------------
 sub       |          1 |           9 |   603980550 |           0 |           29 |   1914455250 |        242 |  1914488162 | 2022-02-23 15:55:46.8994+00
(1 row)

It is recommended to adjust the value of logical_decoding_work_mem (default is 64MB) to set the maximum amount of memory that we can spend for a (each) walsender process. Using this we can avoid many spills to disk at the same time avoiding excessive memory usage.

For example:

postgres=# ALTER SYSTEM SET logical_decoding_work_mem = '512MB';
ALTER SYSTEM
postgres=# select pg_reload_conf();

Conclusion

In this blog post, I want to encourage PostgreSQL users who abandoned logical replication in the past due to its shortcomings to reconsider it again as PostgreSQL 13 and 14 along with Patroni solves most of the difficulties. Lengthy, bulk transactions are known to cause severe problems to logical replication. The effect was very serious in previous versions but with new improvements, it is mitigated to a good extent and expected to reduce the load on the publisher side considerably.

However, this doesn’t mean that it is perfect. Community and developers are aware of lot more areas for improvement, especially improvements on the subscription side. We should expect such changes in the upcoming versions.

Feb
24
2022
--

Percona Monthly Bug Report: February 2022

Percona Bug Report Feb 2022

Percona Bug Report Feb 2022Here at Percona, we operate on the premise that full transparency makes a product better. We strive to build the best open-source database products, but also to help you manage any issues that arise in any of the databases that we support. And, in true open source form, report back on any issues or bugs you might encounter along the way.

We constantly update our bug reports and monitor other boards to ensure we have the latest information, but we wanted to make it a little easier for you to keep track of the most critical ones. These posts are a central place to get information on the most noteworthy open and recently resolved bugs. 

In this February 2022 edition of our monthly bug report, we have the following list of bugs:

 

Percona Server for MySQL/MySQL Bugs

MySQL#105761: mysqldump makes a non-consistent backup with –single-transaction option as it captures the wrong GTID position in the dump file for which data is not included in the dump file. This will further cause issues like replication errors if you are setting up replica using this dump sql file and  GTID position in it.

The issue is caused by changes in MySQL 5.7.36 as part of this bug fix(Bug#32843447: GTID_PURGED IS GETTING EMPTY AND GTID_EXECUTED) resulting in GTID_EXECUTED being gathered at the end of the dump, instead of right after the START TRANSACTION.

To avoid this issue you can use previous( before 5.7.36)versions of mysqldump which is not affected by this change.

Affected version/s: 5.7.36

 

PS-7409 (MySQL#101459): Select Queries like in the below example with more than one value in IN() will skip index use.

Example: select updated_at from t1 where status in (‘abc’, ‘xyz’) and priority != 100 \G

Affected version/s: 5.6,5.7 (Tested with 5.6.50,5.7.32)

 

MySQL#99370: Semi-synchronous replication executes un-acknowledged transactions in case the source node goes down(crashed/failure) before it receives a replication acknowledgment from the replica, it still executes that transaction when the server restarts.

Issue reported for version: 5.7

This has been fixed as a documentation bug by adding the following important note in the documentation: 

https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html 

and earlier release versions:

Important:

With semisynchronous replication, if the master crashes and a failover to a replica is carried out, the failed master should not be reused as the replication master and should be discarded. It could have transactions that were not acknowledged by any replica, which were therefore not committed before the failover. 

 If your goal is to implement a fault-tolerant replication topology where all the servers receive the same transactions in the same order, and a server that crashes can rejoin the group and be brought up to date automatically, you can use Group Replication to achieve this.

 

PS-8052: Executing SHOW PROCESSLIST or accessing INFORMATION_SCHEMA.PROCESSLIST on a server with a terminology_use_previous=’BEFORE_8_0_26′ configuration causing a crash.

Affected version: PS-8.0.26 ,MySQL-8.0.26 and 8.0.27

Fixed version: PS-8.0.27 , MySQL-8.0.28

 

Percona XtraDB Cluster

PXC-3724/PXC-3776: PXC node crashes with long semaphore. This issue occurred due to locking when writing on multiple nodes in the PXC cluster. This is critical as it blocks all nodes to perform any transactions and finally crashes the PXC node.

Affects Version/s: 8.0  [Tested/Reported version 8.0.22,8.0.25]

Fixed Version: 8.0.26

 

Percona Toolkit

PT-1889: Incorrect output when using pt-show-grants for users based on MySQL roles as a result they can not be applied back properly on MySQL server. Due to this, we can not use pt-show-grants for MySQL roles until this issue is fixed.

Affects Version/s:  3.2.1

 

PT-2016: pt-table-checksum fails to build replace query when table lack a primary key (Unique key is present) and text fields are involved.

Affects Version/s:  3.3.1

Fixed Version: 3.4.0

 

Percona Server for MongoDB

PSMDB-892:  RWC defaults pollute the logs with duplicate “Refreshed RWC defaults” messages as a result log is saturated with the message in the title.

Affects Version/s:  4.4.6

Fixed Version: 4.4.8

 

PSMDB-671: createBackup returns ok:1 for archived backup even when there is no disk space available.

Affects Version/s: 4.0.12-6, 4.2.1-1, 3.6.15-3.5

Fixed Version: 3.6.19-7.0, 4.0.20-13, 4.2.9-9

 

Percona Distribution for PostgreSQL

DISTPG-317:  Installing Percona-PostgreSQL13 from its repository, the package dependencies are such it is going to remove PostgreSQL Community 12 installed.

Affects Version/s: 13.4

Fixed Version: Next 13.x release

 

PMM  [Percona Monitoring and Management]

PMM-9341: Deleting NODE from PMM Inventory breaks pmm client-server connection with leaving orphan agent_id somewhere as reference.

Workaround: Reconfigure PMM client-server connection again and read instance to monitoring.

Affects Version/s: 2.x  [Tested/Reported version 2.24]

 

PMM-9156: pmm-agent paths-base option not working for pmm2-client binary installation in PMM 2.23.0. Starting pmm-agent process gives “level=error msg=”Error reading textfile collector directory”

Affects Version/s: 2.x  [Tested/Reported version 2.23]

Fixed Vresion: 2.25.0

 

PMM-7846:  Adding MongoDB instance via pmm-admin with tls option not working and failing with error Connection check failed: timeout (context deadline exceeded).

Affects Version/s: 2.x  [Tested/Reported version 2.13, 2.16]

 

Summary

We welcome community input and feedback on all our products. If you find a bug or would like to suggest an improvement or a feature, learn how in our post, How to Report Bugs, Improvements, New Feature Requests for Percona Products.

For the most up-to-date information, be sure to follow us on Twitter, LinkedIn, and Facebook. 

Quick References:

Percona JIRA

MySQL Bug Report

Report a Bug in a Percona Product

MySQL 8.0.27 Release notes

https://jira.mongodb.org/

___

About Percona:

As the only provider of distributions for all three of the most popular open source databases—PostgreSQL, MySQL, and MongoDB—Percona provides expertise, software, support, and services no matter the technology.

Whether its enabling developers or DBAs to realize value faster with tools, advice, and guidance, or making sure applications can scale and handle peak loads, Percona is here to help.

Percona is committed to being open source and preventing vendor lock-in. Percona contributes all changes to the upstream community for possible inclusion in future product releases.

Feb
23
2022
--

Ciao Baby Portable High Chair

High chairs are important, even if you’re just going to be feeding your child dinner in the living room while watching TV. At some point, you’ll need it so that your baby can eat on their own level. High chairs keep your baby safe and clean while you’re feeding them, and they also help prevent food stains on your furniture.

There are many varieties of high chairs, but there’s one portable model that might be perfect for you. It’s called the Ciao Baby Portable High Chair, and it may just become your go-to high chair!

This product is available online through Amazon, with attractive shipping options. The best part about this particular high chair is that you can fold it up and put it in a bag when you’re done using it, making it portable. You can take this high chair while traveling or to family gatherings.

A closer look at The Ciao Baby Portable High Chair

The Ciao Baby Portable High Chair is one of the most popular baby high chairs on the market today. The portable design makes it an excellent travel highchair, and it’s safe for your child. The design keeps your child in an upright position so you can feed them with ease.

The Ciao Baby is perfect for babies aged 4 months or older. It has a removable tray, and the chair itself folds up so that it easily fits into a bag when you’re finished using it. The tray also comes entirely off of the high chair so that you can clean it with ease.

The Ciao Baby Portable High Chair is an excellent alternative to traditional high chairs and makes a beautiful gift for new parents or expecting parents.

Ciao Baby Portable High Chair Features:

  • 5-point safety harness that keeps your baby safe and secure
  • easy-to-clean removable tray – no need to worry about spills and mess
  • durable construction, so the high chair can last you a long time
  • spacious and comfortable, to keep your baby happy
  • lightweight, for convenience
  • comes with a carry bag, for easier traveling
  • available in various colors to match your taste

The Ciao Baby Portable High Chair is the perfect combination of style, convenience, and comfort. It sets up in seconds to provide your child with a safe eating environment at home or while traveling.

It’s also great for when you’re working in the garden, cooking dinner, or want an extra high chair for your other children if you have them.

How to clean the Ciao Baby Portable High Chair?

The Ciao Baby Portable High Chair is easy to clean. The tray comes off for easier cleaning, and you can either put it in the dishwasher or wash it by hand once your child has finished eating.

You should also wipe down the high chair itself when your baby is done with dinner to remove any food particles that may have stuck to it. The Ciao Baby Portable High Chair cleans easily with just water, but you can also use a mild detergent.

Bleach or other solvent cleaners should not be used on plastic or cloth since harm to the material may occur.

Is the Ciao Baby Portable High Chair worth buying?

If you’re looking for a portable high chair that your baby can use while traveling, then the Ciao Baby Portable High Chair is the perfect solution. It’s lightweight and folds up to go anywhere with you.

You can also use it as a temporary high chair for home if you don’t already have one, or keep it in your car so that you always have a safe place to feed your baby while on the go. Travel with your baby is easier than ever!

The post Ciao Baby Portable High Chair appeared first on Comfy Bummy.

Feb
21
2022
--

Talking Drupal #335 – LocalGov

Today we are talking about LocalGov Drupal.

www.talkingDrupal.com/335

Topics

  • LocalGov description
  • What a council is and how LocalGov helps
  • Who it’s for
  • Publicly owned asset
  • How distributions reduce cost
  • Layout Builder vs Paragraphs
  • Headless / Decoupled
  • Central gov.uk design system
  • Drupal version
  • Updating
  • Roadmap
  • How to help

Resources

Guests

Will Callaghan – localgovdrupal.org @willguv Finn Lewis – agile.coop @finnlewis Mark Conroy – annertech.com @markconroy

Hosts

Nic Laflin – www.nLighteneddevelopment.com @nicxvan John Picozzi – www.epam.com @johnpicozzi Abby Bowman – www.linkedin.com/in/arbowman @abowmanr

Feb
21
2022
--

Updated Percona Distributions for MongoDB, PMM 2.26.0: Release Roundup February 21, 2022

Percona Software Release Feb 21 2022

It’s time for the release roundup!

Percona Software Release Feb 21 2022Percona is a leading provider of unbiased open source database solutions that allow organizations to easily, securely, and affordably maintain business agility, minimize risks, and stay competitive.

Our Release Roundups showcase the latest Percona software updates, tools, and features to help you manage and deploy our software. It offers highlights and critical information, as well as links to the full release notes and direct links to the software or service itself to download.

Today’s post includes those releases and updates that have come out since February 7, 2022. Take a look!

 

Percona Distribution for MongoDB 4.4.12

On February 7, 2022, we released Percona Distribution for MongoDB 4.4.12. It is a freely available MongoDB database alternative, giving you a single solution that combines enterprise components from the open source community, designed and tested to work together. This release includes improvements and bug fixes provided by MongoDB and included in Percona Server for MongoDB. The most notable from them are the following:

  • Defined a timeout for a health check process and throw an error when the process fails to complete within a timeout. This prevents health check to hang.
  • Added the ability to transition through the valid states of the fault manager, and the interface to observer and log its state transitions.
  • Fixed broken OP_QUERY exhaust cursor implementation
  • Added the repairShardedCollectionChunksHistory command to restore history fields for some chunks. This aims to fix broken snapshot reads and distributed transactions.

Download Percona Distribution for MongoDB 4.4.12

 

Percona Distribution for MongoDB 5.0.6

Percona Distribution for MongoDB 5.0.6 was released on February 10, 2022. It is based on Percona Server for MongoDB 5.0.6-5 and Percona Backup for MongoDB 1.6.1 and includes bug fixes provided by MongoDB and included in Percona Server for MongoDB. The most notable from them are the following:

  • Fixed an issue with inconsistent data observed during the direct upgrade from 4.4.3 and 4.4.4 to 4.4.8+ and 5.0.2+. Data inconsistency was caused by the incorrect checkpoint metadata to sometimes be recorded by MongoDB versions 4.4.3 and 4.4.4. WiredTiger used this metadata during node startup that could lead to data corruption and could cause the DuplicateKey error. The fix requires the upgrade to versions 4.4.11+ or 5.0.5+. For details, refer to WT-8395.
  • Fixed issue unavailability of a shard in sharded clusters. Affects MongoDB versions 5.0.0 – 5.0.5.
  • Fixed time-series bucket OID collisions by adding the difference between the actual timestamp and the rounded timestamp to the instance portion of the OID.

Download Percona Distribution for MongoDB 5.0.6

 

Percona Server for MongoDB 4.4.12-12

Percona Server for MongoDB 4.4.12-12 was released on February 7, 2022. It is an enhanced, source-available and highly-scalable database that is a fully-compatible, drop-in replacement for MongoDB Community Edition. It is based on MongoDB 4.4.11 and 4.4.12 and supports MongoDB 4.4.11 – 4.4.12 protocols and drivers. Bug fixes and improvements provided by MongoDB are included in Percona Server for MongoDB.

Download Percona Server for MongoDB 4.4.12-12

 

Percona Server for MongoDB 5.0.6-5

On February 10, 2022, we released Percona Server for MongoDB 5.0.6-5. A release highlight includes a fix for an issue with inconsistent data observed during the direct upgrade from 4.4.3 and 4.4.4 to 4.4.8+ and 5.0.2+. Data inconsistency was caused by the incorrect checkpoint metadata to sometimes be recorded by MongoDB versions 4.4.3 and 4.4.4. WiredTiger used this metadata during node startup that could lead to data corruption and could cause the DuplicateKey error. The fix requires the upgrade to versions 4.4.11+ or 5.0.5+.

Download Percona Server for MongoDB 5.0.6-5

 

Percona Monitoring and Management 2.26.0

February 8, 2022, saw the release of Percona Monitoring and Management 2.26.0, a free and open source platform for managing and monitoring MySQL, MongoDB, and PostgreSQL performance. Highlights in this release include new experimental dashboards, SMTP configuration verification, and major changes for Integrated Alerting (Technical Preview).

Download Percona Monitoring and Management 2.26.0

 

Percona XtraDB Cluster 5.7.36-31.55

On February 16, 2022, Percona XtraDB Cluster 5.7.36-31.55 was released. Our free, open source, enterprise-grade solution includes the high availability and security features your business requires to meet your customer expectations and business goals. Release highlights are bug fixes for MySQL 5.7.36 provided by Oracle, including:

  • Fix for the possibility of a deadlock or failure when an undo log truncate operation is initiated after an upgrade from MySQL 5.6 to MySQL 5.7.
  • Fix for when a parent table initiates a cascading SET NULL operation on the child table, the virtual column can be set to NULL instead of the value derived from the parent table.
  • On a view, the query digest for each SELECT statement is now based on the SELECT statement and not the view definition, which was the case for earlier versions.

Download Percona XtraDB Cluster 5.7.36-31.55

 

That’s it for this roundup, and be sure to follow us on Twitter to stay up-to-date on the most recent releases! Percona is a leader in providing best-of-breed enterprise-class support, consulting, managed services, training, and software for MySQL, MongoDB, PostgreSQL, MariaDB, and other open source databases in on-premises and cloud environments.

Feb
16
2022
--

Monitoring MongoDB Collection Stats with Percona Monitoring and Management

Monitoring MongoDB Collection Stats

Monitoring MongoDB Collection StatsOne approach to get to know a MongoDB system we are not familiar with is to start by checking the busiest collections. MongoDB provides the top administrative command for this purpose.

From the mongo shell, we can run db.adminCommand(“top”) to get a snapshot of all the collections at a specific point in time:

...
		"test.testcol" : {
			"total" : {
				"time" : 17432,
				"count" : 58
			},
			"readLock" : {
				"time" : 358,
				"count" : 57
			},
			"writeLock" : {
				"time" : 17074,
				"count" : 1
			},
			"queries" : {
				"time" : 100,
				"count" : 1
			},
			"getmore" : {
				"time" : 0,
				"count" : 0
			},
			"insert" : {
				"time" : 17074,
				"count" : 1
			},
			"update" : {
				"time" : 0,
				"count" : 0
			},
			"remove" : {
				"time" : 0,
				"count" : 0
			},
			"commands" : {
				"time" : 0,
				"count" : 0
			}
		}
		...

In the extract above we can see some details about the testcol collection. For each operation type, we have the amount of server time spent (measured in microseconds), and a counter for the number of operations issued. The total section is simply the sum for all operation types against the collection.

In this case, I executed a single insert and then a find command to check the results, hence the counters are one for each of those operations.

So by storing samples of the above values in a set of metrics, we can easily see the trends and historical usage of a MongoDB instance.

Top  Metrics in Percona Monitoring and Management (PMM)

PMM 2.26 includes updates to mongodb_exporter so we now have the ability to get metrics using the output of the MongoDB top command.

For example:

MongoDB Percona Monitoring and Management

As you can see, the metric names correlate with the output of the top command we saw. In this release, the dbname and collection name is part of the metric name (that is subject to change in the future based on community feedback).

Collection and Index Stats

In addition to this, PMM 2.26 also includes the ability to gather database, collection, and index statistics. Using these metrics we can monitor collection counts, data growth, and index usage over time.

For example, we can collect the following information about a database:

PMM Collection and Index Stats

And here are the colstats metrics for the test.testcol collection:

PMM metrics

Note: By default, PMM won’t collect this information if you have more than 200 collections (this number is subject to change). The reason is to avoid too much overhead in metrics collection, which may adversely affect performance. You can override this behavior by using the –max-collections-limit option.

Enabling the Additional Collectors

The PMM client starts by default only with the diagnosticdata and replicasetstatus collectors enabled. We can run the PMM client with the –enable-all-collectors argument, to make all the new metrics available. For example:

pmm-admin add mongodb --username=mongodb_exporter --password=percona --host=127.0.0.1 --port=27017 --enable-all-collectors

If we want to override the limit mentioned above, use something like this:

pmm-admin add mongodb --username=mongodb_exporter --password=percona --host=127.0.0.1 --port=27017 --enable-all-collectors -–max-collections-limit=500

We also have the ability to enable only some of the extra collectors. For example, if you want all collectors except topmetrics, specify:

pmm-admin add mongodb --username=mongodb_exporter --password=percona --host=127.0.0.1 --port=27017 --enable-all-collectors --disable-collectors=topmetrics

We can also filter which databases and collections we are interested in getting metrics about. The optional argument –stats-collections can be set with a namespace.

For example:

–stats-collections=test (get data for all collections in test db)
–stats-collections=test.testcol (get data only from testcol collection of testdb)

Also, check the documentation page for more information.

Creating Dashboards

We can easily create dashboards using the newly available metrics. For example, to see the index usages, we can use the following promSQL expression:

{__name__ =~ "mongodb_.*_accesses_ops"}

This is what the dashboard would look like:

MongoDB dashboard

Note: If the image above is too small, you can open it in a new browser tab to see it better.

Conclusion

We can use these new metrics to create dashboards with the collections most written to (or most read from). We can also see what the characteristics of the workload are at a glance to determine if we are dealing with a read-intensive, mixed, or write-intensive system.

One of the most important uses for these new collectors and metrics is performance tuning. By knowing more about your top or “hottest” collections, you will likely be able to better tune your queries and indexing to improve overall performance. These new metrics on collections will be very helpful for performance tuning

Keep in mind these features are currently a technical preview, so they are disabled by default.

Percona Monitoring and Management is a best-of-breed open source database monitoring solution. It helps you reduce complexity, optimize performance, and improve the security of your business-critical database environments, no matter where they are located or deployed.

Download Percona Monitoring and Management Today

Feb
16
2022
--

Economical Comparison of AWS CPUs for MySQL (ARM vs Intel vs AMD)

Economical Comparison of AWS CPUs for MySQL

Economical Comparison of AWS CPUs for MySQLIt is always hard to select a CPU for your own purpose. You could waste hours reviewing different benchmarks, reviews, and bloggers, and in the end, we would limit all our requirements to performance and price. For performance measuring we already have some specific metrics (e.g. in MHz to some specific tool), however, for economic comparison, it is quite hard.  Mostly we are limited by our budget. Again, for our personal purposes, we are limited only with the cash in our pockets. It is easy to compare only two or three CPUs; it is required just to compare their price and performance and then create a simple bar plot and then check the results. However, what do you do if you have at least three types of CPU, a different number of CPUs cores on board, and seven different scenarios?  It was a challenge to do it for performance, and for economic efficiency, it has become a nightmare. For a one-time purchase, it should be easier than for the long-term and for rent (as we do for renting CPU on AWS).

Since October 2021, there have been three performance reviews for CPUs for MySQL (mostly it was comparing ARM with others):

Comparing Graviton (ARM) Performance to Intel and AMD for MySQL (Part 1)

Comparing Graviton (ARM) Performance to Intel and AMD for MySQL (Part 2)

Comparing Graviton (ARM) Performance to Intel and AMD for MySQL (Part 3)

I thought it was hard to visualize multiple scenarios for multiple processor types and multiple CPU amounts. The real challenge appeared when it was needed to compare the economical efficiency of these CPUs. There were four attempts to write this article. As a professional, at first, I wanted to show all numbers and details, because I didn’t want to be subjective, but rather allow readers to make decisions by themselves. In this case, that variant of those articles became so long and unreadable. So I’ve decided to simplify and present it without all the details (all details graphs and numbers readers could find on our GitHub arm_cpu_comparison_m5, csv_file_with_all_data_m5, arm_cpu_comparison_c5, csv_file_with_all_data_c5arm_cpu_comparison_m6, csv_file_with_all_data_m6).

The main goal of this post is to show a general picture of the economical efficiency of different CPUs for MySQL in comparison to each other. The main value of this post is to provide performance and economical comparison of different CPUs for MySQL (AWS only). It should help readers to see alternatives for their existing solution in performance and see if it is possible to save some money using a similar EC2 with a different CPU. Also, it will be useful for everyone for planning a migration or planning infrastructure for the long term.

This post contains a lot of technical information based on a large amount of data. It tries to show the efficiency of all instances from previous test runs. So it would be a comparison of m5.* (Intel), m5a.* (AMD). m6g.* (Graviton), c5.* (Intel), c5a.* (AMD), c5g.* (Graviton), m6i.* (Intel), and m6a.* (AMD) types of instances.

In general, there could be a lot of questions about methodology and comparison approach, and I would be glad to hear (read) other opinions and try to do it much better and more efficiently. 

The main idea was to find what EC2 (with what CPU type) is more economical to use and more effective from a performance point of view for MySQL For these purposes, we would show two main indicators: 

  1. How many queries we could run during one hour (because all of us pay hourly for EC2 instances and because AWS shows hourly prices).
  2. How many queries could be done for one US dollar. It was needed to create some universal economical value. So I thought that performance for one USD should be universal for economical comparison.

All other conclusions would be the results of these indicators. 

The next few points are required to describe the approach of testing and our test description

DISCLAIMER
  1. Tests were run on the M5.*, M6I.*, C5.* (Intel), M5a.*, C5a.*, M6a.* (AMD),  M6g.*,C6g.* (Graviton) EC2 instances in the US-EAST-1 region. (List of EC2 see in the appendix). We select only the same class of instances without any additional upgrades like M5n (network) or M5d (with fast SSD). The main goal is to take the same instances with only differences in CPU types.  The main goal was to calculate price efficiency with only one variable CPU type.
  2. Monitoring was done with Percona Monitoring and Management.
  3. OS: Ubuntu 20.04 LTS
  4. Load tool (sysbench) and target DB (MySQL) installed on the same EC2 instance. It was done to exclude any network impact. It could have minimal impact on performance results because all instances are in the same conditions, and results are comparable.
  5. Oracle MySQL Community Server — 8.0.26-0 — installed from official packages (it was installed from Ubuntu repositories).
  6. Load tool: sysbench —  1.0.18
  7. innodb_buffer_pool_size=80% of available RAM
  8. Test duration is five minutes for each thread and then 90 seconds warm down before the next iteration.
  9. Each test was at least run three times (to smooth outliers / to have more reproducible results). Then results were averaged for graphs.
  10. We are going to use a “high-concurrency” scenario definition for scenarios when the number of threads would be bigger than the number of vCPU. And “low-concurrent” scenario definition with scenarios where the number of threads would be less or equal to a number of vCPU on EC2.
  11. We were comparing MySQL behavior on the same class of EC2, not CPU performance. This time we just want to know how many queries could be done for one US dollar and during one payment hour.
  12. The post is not sponsored by any external company. It was produced using only Percona resources. We do not control what AWS uses as CPU in their instances, we only operate with what they offer.
  13. Some graphs are simplified, to make them easy to understand. There are too many conditions to visualize in one graph. Each one that is simplified is commented on directly.

 

TEST case description

Prerequisite:
To use only CPU (without disk and network) we decided to use only read queries from memory. To do this we did the following actions.

Create DB with 10 tables with 10 000 000 rows each table using sysbench tool%
sysbench oltp_read_only –threads=10 –mysql-user=sbtest –mysql-password=sbtest –table-size=10000000 –tables=10 –db-driver=mysql –mysql-db=sbtest prepare
Load all data to LOAD_buffer with reading queries , using sysbench:
sysbench oltp_read_only –time=300 –threads=10 –table-size=1000000 –mysql-user=sbtest –mysql-password=sbtest –db-driver=mysql –mysql-db=sbtest run

Test:
Run in a loop for same scenario but with different concurrency THREADs (2,4,8,16,32,64,128) on each EC2 (again using sysbench tool)
sysbench oltp_read_only –time=300 –threads=${THREAD} –table-size=100000 –mysql-user=sbtest –mysql-password=sbtest –db-driver=mysql –mysql-db=sbtest run

 

Result Overview

It was decided to visualize results in some specific lollipops graphs. These graphs will show at least both variables – performance per hour and performance per dollar.

Also, there are simple point plots with several dimensions. It will show not only point values but also the type of CPU (by color) and the number of vCPU (by shape).

All CPU colors will be the same throughout this article. 

  • Graviton – orange
  • Intel – blue
  • AMD – red

To simplify visualization it was decided to leave only results when the load (in the number of active threads) had been equal to the number of vCPU on an EC2 instance. In most cases, it shows the best results, due to minimal 95th percentile latency. However, there were a few exceptions, which we will talk about later.

Request Per Hour vs. Price For Equal Load

First, let’s review simple dependency price and performance at plot 1.1.

Plot 1.1. Number of requests per hour compared to EC2 instance price

Number of requests per hour compared to EC2 instance price

Plot 1.2. Number of requests per hour compared to EC2 instance price with EC2 labels

Plot 1.2. illustrates the same information as plot 1.1. with EC2 labels.

Request Per Dollar vs. Price

Plot 2.1. Number of requests per one USD comparing with instance price for equal load

Number of requests per one USD comparing with instance price for equal load

Plot 2.1. Showed an approximate number of transactions that could be generated for one USD.  it shows much more interesting pictures than plot 1.1 Data shows how many queries MySQL could execute for one USD. Looks like the best economic performance shows 16 cores EC2, next goes 32 Intel and AMD, then went eight cores AMD. What is interesting here is that for one USD, two cores AMD could execute a little bit more queries than 64 cores Intels EC2 per one USD. It is definitely that 64 cores Intel could execute more queries for an hour, but not always it is required to do it in one hour.

Plot 2.2. Number of requests per one USD comparing with instance price for equal load with EC2 instance labels

Number of requests per one USD comparing with instance price for equal load with ec2 instance labels

RATING

Plot 3.1. All EC2 sorted by approximate amount of transactions they could generate during one hour.

efficiency of CPUS MySQL AWS

Plot 3.1. Illustrates two variables. The number of transactions each EC2 could generate for one hour (purple circle) and the number of executed transactions it could execute for one USD. This rating is sorted by performance. And there is no surprise more virtual cores exist in EC2 more transactions it could generate. On the top is the latest m6i.16xlarge (Intel) and m6a.16xlarge (AMD). It is the latest “general-purpose” instance. What is interesting here is that on the third and fourth place it is seen the same Graviton vCPU but in two different instance types c5g.16xlarge (third place) and m6g.16xlarge. Looks like a “compute-optimized” instance really has some internal optimization, because on average it showed better performance than a general-purpose Graviton instance.

Plot 3.2. All EC2 sorted by approximate amount of transaction they could generate for one USD

MYSQL costs

Plot 3.2. Illustrates two variables. The number of transactions each EC2 could generate for one hour (purple circle) and the number of executed transactions it could execute for one USD. This rating is sorted by economic efficiency. And here we got a surprise: it appears that the best economic efficiency has EC2 instances with 16 and 32 vCPU on board. On the top there is m6a.4xlarge (AMD, 16 vCPU) which is a little more efficient than m6i.4xlarge (Intel, 16 vCPU), however, Intel, was a little bit performance efficient. In third place, m6i.8xlarge (Intel with 32 vCPU) was a little less economically efficient, than EC2 from second place. And Graviton is only in fourth place. However, these results are valid only, when the load was equal to the number of vCPU. Is important because performance Intel and AMD vs Graviton have absolutely different results. In most cases, Intel and AMD had maximum performance when the load was equal (additional visualization would be provided next on plot 5.1. and plot 5.2.).

How I Would Select a CPU For The Next Project

The next words can’t be an official recommendation; just the option of the person to be stuck in performance data of test results and spend a few months here.  

To select some vCPU for MySQL I would be oriented on my previous research. At first, I would focus on the load. How many transactions per second (or per hour) my DB should handle. And after that, I would select the cheapest EC2 instance for that load.

For example, my DB should handle 500 Million transactions per hour. In this case, I would build some graphs with the cheapest instances from different CPU developers. And then just select the cheapest one.

Plot 4.1. Cheapest EC2 instances that can handle 500 million transactions per hour

Cheapest EC2 instances that can handle 500 million transactions per hour

Plot 4.1. Showed the cheapest instance that could handle 500 million transactions per hour. These results could be reached by overloading the system eight times. This load could handle EC2 with 16 vCPU and they easily could handle this load even if there would be a load with 128 active threads. It is talking only about reading translations right now. And we’re talking about an hour because most of us are oriented on hourly price on AWS, so it should be oriented on hourly load, even if it is not constant value during the hour. 

However, let’s review the same example for load in transaction per second. The approach would be the same. Take your load and find the cheapest instance that could handle your load.  For example, let’s take a load of 10,000 transactions per second (a kindly reminder that we are talking about read transactions). 

Plot 4.2. Cheapest EC2 instances that can handle 10,000 transactions per second

Cheapest EC2 instances that can handle 10,000 transactions per second

Plot 4.2. Showed that 10k transactions per second could be handled by two vCPU compute-optimized instances – c5.large(Intel), c5a.large(AMD), c6g.large(Graviton). Again Graviton became cheaper. It is cheaper than Intel by 20 percent and 9 percent compared with AMD. 

The short table you could find in the appendix, full one on Github (with all scenarios).

But if someone doesn’t want to build the graph or analyze the table,  I’ve built graph (almost heatmap) plot 4.3 (transactions per hour) and plot 4.4 (transaction per second).

The next plots show the cheapest EC2 instances that could handle some load (on the y-axis) for some specific class of these instances depending on the number of vCPU (on the x-axis). By color, it is easy to identify the type of CPU, but it was labeled the cheapest EC2 instance in the cell. Of course, some other instance could also handle that load but in the cell label of the cheapest one. 

Short summary regarding plot 4.3. and plot 4.4. Graviton is the cheapest solution in most cases, however, it can’t handle the maximal load that Intel or AMD can.

Plot 4.3. The cheapest EC2 instances for a particular load in transaction per hour depends on the number of vCPU

cheapest EC2 instances for a particular load in transaction per hour depends on the number of vCPU

Plot 4.4. The cheapest EC2 instances for a particular load in transaction per second depends on the number of vCPU

In case someone wants to identify the cheapest instance for some particular load and doesn’t care about vCPU onboard – welcome to plot 4.4.1., which shows the cheapest EC2 for some load when the load in an active thread was equal to the number of vCPU on board.

Plot 4.4.1. Cheapest EC2 instance for required load with a load that was equal to the number of vCPU on an instance

Cheapest EC2 instance for required load with a load that was equal to the number of vCPU on an instance

Plot 4.4.2. Cheapest EC2 instance for required load with a load that was maximal during research

There are not a lot of differences between plot 4.4.1 and plot 4.4.2. However, sometimes Intel overran AMD. But in the overall picture, Graviton is still cheaper in most cases.

Important Exceptions

Next, there were a few exceptions that are required to talk about. Plots and scenarios were taken from its particular research, so it could be that they are not equal to the picture above. All details will be provided.

Plot 5.1. Graviton behavior on higher load

Plot 5.1. Illustrates that Graviton (m6g.16xlarge with 64 vCPU) showed better performance on higher loads. Previously all results were shown when loads were equal to the amount of vCPU. However, most CPUs did not show impressive performance with loads bigger than the number of vCPU. On the other hand, Graviton (most of the time) showed better performance than on equal load. An example of it you could see on the first two lines on plot 5.1. This is a very interesting feature of Gravitons, and this feature is reproducible. On plot 5.1.1. it is seen that Graviton on EC2 with 16, 32, 64 vCPU on board produces more transactions on double load than on equal load. In percentages, it is an additional boost of 10 percent when we overload Graviton EC2 compared with other CPUs, and their result could be a statistical error.

Plot 5.1.1 Performance comparison of  high-performance EC2 instances with an equal and double load

high-performance EC2 instances with an equal and double load

Plot 5.1.2 Advantage of high concurrency instances with double load over equal load in percents

Plot 5.2. Economical efficiency of 8 and 16 cores EC2

Economical efficiency of 8 and 16 cores EC2

The next interesting exception is shown in plot 5.2. In the case of different loads (not only when load max or equal to the number of vCPU), Graviton also showed the best economic efficiency compared with all other vCPUs. On plot 5.2. I left only the results with maximal load and we could see that Graviton had the best economical potential.  What is more interesting is that all EC2 with 8 and 16 vCPU on board were on the top of this rating. Looks like it is more economically effective to use 8 or 16 core instances than others. If the load near 200k per second (read transaction) is fine for more than 16 cores, EC2 instances are the best economic value for you (look at plot 4.4.2).

Plot 5.4. Economical efficiency of 12 core Intel vs 16 core Graviton and AMD

Economical efficiency of 12 core intel vs 16 cores Graviton and AMD

Sometimes some particular load could handle instances with fewer vCPU, but even in this case, it could be more expensive than using EC2 with more vCPU. Plot 5.4. showed this example. It was the maximum load that all three CPUs could handle over 2.1 billion transactions. EC2 instances that could handle it are c6g.16xlarge (Graviton with 64 vCPU), m6i.12xlarge (Intel with 48 vCPU), and m6a.16xlarge (AMD with 64 vCPU). Here EC2 with AMD appeared to be more expensive than its competitors. Next is Intel with less vCPU onboard and cheaper price, 48 vCPU compared to AMDs 64. However, Gravitons EC2 with 64 cores on board could handle the same load while cheaper than Intel with less vCPU. It could be done few conclusions: 

  1. The number of CPUs does not always correlate with higher performance
  2. It is possible to find a better price and better conditions  

Final Thoughts

I’ve spent a few weeks preparing a script to run benchmark tests. It took a week to run and re-run all the benchmark tests. And it took months to write this article. Multiple attempts to describe everything lead me to this show article with a lot of limitations and ranges. It is a really difficult thing to speak about difficult things in easy matters. It is easy to compare one dimension, but it is harder to compare multiple dimensions like performance for different CPU types which depend on different numbers of vCPU and in different test cases. But even this is easier because the previous time we compared performance to performance. This time it was required to compare multi-dimensional performance to economic efficiency and prices. It is like comparing the calories of different fruits with their prices and identifying the best one, without thinking about personal tastes. 

This task became quite difficult for me personally. However, I think this is a good point to start a discussion about it. I’ve started thinking about its unique comparable measurement like the number of transactions for one USD. Based on this measurement, EC2 instances with Graviton CPU become most effective in most cases. It didn’t show equal performance measurements like the latest Intel and AMD, but if it joins the economy and performance it is definitely a good choice to try it in future DB projects.

PS: On our GitHub — there are scripts to reproduce this research and more interesting graphs, that couldn’t be inserted here.

APPENDIX

Simplified table with results and list of EC2 that were used in research

 

VM_type Number_of_threads cpu_amount avg_qps price_usd cpu_type
c5a.large 2 2 19287 0.077 AMD
m5a.large 2 2 12581 0.086 AMD
m6a.large 2 2 23280 0.0864 AMD
c5a.xlarge 4 4 29305 0.154 AMD
m5a.xlarge 4 4 21315 0.172 AMD
m6a.xlarge 4 4 37681 0.1728 AMD
c5a.2xlarge 8 8 81575 0.308 AMD
m5a.2xlarge 8 8 58396 0.344 AMD
m6a.2xlarge 8 8 98622 0.3456 AMD
c5a.4xlarge 16 16 158539 0.616 AMD
m5a.4xlarge 16 16 113172 0.688 AMD
m6a.4xlarge 16 16 211681 0.6912 AMD
m5a.8xlarge 32 32 189879 1.376 AMD
m6a.8xlarge 32 32 376935 1.3824 AMD
c5a.16xlarge 64 64 482989 2.464 AMD
m5a.16xlarge 64 64 312920 2.752 AMD
m6a.16xlarge 64 64 612503 2.7648 AMD
c6g.large 2 2 17523 0.068 Graviton
m6g.large 2 2 17782 0.077 Graviton
c6g.xlarge 4 4 30836 0.136 Graviton
m6g.xlarge 4 4 31415 0.154 Graviton
c6g.2xlarge 8 8 61517 0.272 Graviton
m6g.2xlarge 8 8 65521 0.308 Graviton
c6g.4xlarge 16 16 156914 0.544 Graviton
m6g.4xlarge 16 16 155558 0.616 Graviton
m6g.8xlarge 32 32 298258 1.232 Graviton
c6g.16xlarge 64 64 542983 2.176 Graviton
m6g.16xlarge 64 64 534836 2.464 Graviton
c5.large 2 2 19751 0.085 Intel
m5.large 2 2 17836 0.096 Intel
m6i.large 2 2 23012 0.096 Intel
c5.xlarge 4 4 33891 0.17 Intel
m5.xlarge 4 4 33937 0.192 Intel
m6i.xlarge 4 4 40156 0.192 Intel
c5.2xlarge 8 8 81039 0.34 Intel
m5.2xlarge 8 8 68327 0.384 Intel
m6i.2xlarge 8 8 86793 0.384 Intel
c5.4xlarge 16 16 178295 0.68 Intel
m5.4xlarge 16 16 162387 0.768 Intel
m6i.4xlarge 16 16 225371 0.768 Intel
m5.8xlarge 32 32 313932 1.536 Intel
m6i.8xlarge 32 32 443327 1.536 Intel
m5.16xlarge 64 64 483716 3.072 Intel
m6i.16xlarge 64 64 803180 3.072 Intel

 

My.cnf

My.cnf

 

[mysqld]

ssl=0

performance_schema=OFF

skip_log_bin

server_id = 7

 

# general

table_open_cache = 200000

table_open_cache_instances=64

back_log=3500

max_connections=4000

 join_buffer_size=256K

 sort_buffer_size=256K

 

# files

innodb_file_per_table

innodb_log_file_size=2G

innodb_log_files_in_group=2

innodb_open_files=4000

 

# buffers

innodb_buffer_pool_size=${80%_OF_RAM}

innodb_buffer_pool_instances=8

innodb_page_cleaners=8

innodb_log_buffer_size=64M

 

default_storage_engine=InnoDB

innodb_flush_log_at_trx_commit  = 1

innodb_doublewrite= 1

innodb_flush_method= O_DIRECT

innodb_file_per_table= 1

innodb_io_capacity=2000

innodb_io_capacity_max=4000

innodb_flush_neighbors=0

max_prepared_stmt_count=1000000 

bind_address = 0.0.0.0

[client]

Feb
14
2022
--

Talking Drupal #334 – Managing Drupal Teams in Government

Today we are talking about Leading a Drupal Team in Government with Abigail Bowman and Laura Larrimore.

www.talkingDrupal.com/334

Topics

  • John – Kids listening to show – Alexa and silly songs – Lando pantheon recipe
  • Abby – Paper room craft – GOTW Pokemon Arceus
  • Laura – Olympics
  • Nic – Storybook
  • FL Drupal Camp
  • Abby’s Game of the Week
  • Getting involved in management
  • Current projects
  • Uniqueness of government
  • Building and maintaining a strong team
  • Flexibility
  • Onboarding
  • Training
  • Buy in from executives
  • Managing changing expectations

Resources

Guests

Laura Larrimore

Hosts

Nic Laflin – www.nLighteneddevelopment.com @nicxvan John Picozzi – www.epam.com @johnpicozzi Abby Bowman – www.linkedin.com/in/arbowman @abowmanr

MOTW

Menu breadcrumb This module allows you to use the menu the current page belongs to for the breadcrumb, generating breadcrumbs from the titles of parent menus.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com