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

Recently, AWS presented its own CPU on ARM architecture for server solutions.

It was Graviton. As a result, they update some lines of their EC2 instances with new postfix “g” (e.g. m6g.small, r5g.nano, etc.). In their review and presentation, AWS showed impressive results that it is faster in some benchmarks up to 20 percent. On the other hand, some reviewers said that Graviton does not show any significant results and, in some cases, showed fewer performance results than Intel.

We decided to investigate it and do our research regarding Graviton performance, comparing it with other CPUs (Intel and AMD) directly for MySQL.

Disclaimer

1. The test is designed to be CPU bound only, so we will use a read-only test and make sure there is no I/O activity during the test.
2. Tests were run  on m5.* (Intel) , m5a.* (AMD),  m6g.*(Graviton) EC2 instances in the US-EAST-1 region. (List of EC2 see in the appendix).
3. Monitoring was done with Percona Monitoring and Management (PMM).
4. OS: Ubuntu 20.04 TLS.
5. Load tool (sysbench) and target DB (MySQL) installed on the same EC2 instance.
6. MySQL– 8.0.26-0 — installed from official packages.
7. Load tool: sysbench —  1.0.18.
8. innodb_buffer_pool_size=80% of available RAM.
9. Test duration is five minutes for each thread and then 90 seconds warm down before the next iteration. 
10. Tests were run three times (to smooth outliers or have more reproducible results), then results were averaged for graphs. 
11. We are going to use high concurrency scenarios for those scenarios when the number of threads would be bigger than the number of vCPU. And low concurrent scenario with scenarios where the number of threads would be less or equal to a number of vCPU on EC2.
12. Scripts to reproduce results on our GitHub.

Test Case

Prerequisite:

1. Create DB with 10 tables with 10 000 000 rows each table

2. Load all data to LOAD_buffer

Test:

Run in a loop for same scenario but  different concurrency THREAD (1,2,4,8,16,32,64,128) on each EC2.

Results:

Result reviewing was split into 3 parts:

1. for “small” EC2 with 2, 4, and 8 vCPU
2. for “medium” EC2 with 16 and 32 vCPU
3. for  “large” EC2 with 48 and 64 vCPU

This “small”, “medium”, and “large” splitting is just synthetic names for better reviewing depends on the amount of vCPu per EC2
There would be four graphs for each test:

1. Throughput (Queries per second) that EC2 could perform for each scenario (amount of threads)
2. Latency 95 percentile that  EC2 could perform for each scenario (amount of threads)
3. Relative comparing Graviton and Intel
4. Absolute comparing Graviton and Intel

Validation that all load goes to CPU, not to DISK I/O, was done also using PMM (Percona Monitoring and Management). 

From pic.0.1, we can see that there was no DISK I/O activity during tests, only CPU activity. The main activity with disks was during the DB creation stage.

Result for EC2 with 2, 4, and 8 vCPU

 

 

 

OVERVIEW:

1. AMD has the biggest latencies in all scenarios and for all EC2 instances. We won’t repeat this information in all future overviews, and this is the reason why we exclude it in comparing with other CPUs in percentage and numbers values (in plots 1.3 and 1.4, etc).
2. Instances with two and four vCPU Intel show some advantage for less than 10 percent in all scenarios.
3. However, an instance with 8 vCPU intel shows an advantage only on scenarios with threads that less or equal amount of vCPU on EC2.
4. On EC2 with eight vCPU, Graviton started to show an advantage. It shows some good results in scenarios when the number of threads is more than the amount of vCPU on EC2. It grows up to 15 percent in high-concurrency scenarios with 64 and 128 threads, which are 8 and 16 times bigger than the amount of vCPU available for performing.
5. Graviton start showing an advantage on EC2 with eight vCPU and with scenarios when threads are more than vCPU amount. This feature would appear in all future scenarios – more load than CPU, better result it shows.

 

Result for EC2 with 16 and 32 vCPU

 

 

 

OVERVIEW:

1. In scenarios with the same load for ec2 with 16 and 32 vCPU, Graviton is continuing to have advantages when the amount of threads is more significant than the amount of available vCPU on instances.
2. Graviton shows an advantage of up to 10 percent in high concurrency scenarios. However, Intel has up to 20 percent in low concurrency scenarios.
3. In high-concurrency scenarios, Graviton could show an incredible difference in the number of (read) transactions per second up to 30 000 TPS.

Result for EC2 with 48 and 64 vCPU

 

 

 

OVERVIEW:

1. It looks like Intel shows a significant advantage in most scenarios when its number of threads is less or equal to the amount of vCPU. It seems Intel is really good for such kind of task. When it has some additional free vCPU, it would be better, and this advantage could be up to 35 percent.
2. However, Graviton shows outstanding results when the amount of threads is larger than the amount of vCPU. It shows an advantage from 5 to 14 percent over Intel.
3. In real numbers, Graviton advantage could be up to 70 000 transactions per second over Intel performance in high-concurrency scenarios.

Total Result Overview

 

 

 

Conclusions

1. ARM CPUs show better results on EC2 with more vCPU and with higher load, especially in high-concurrency scenarios.
2. As a result of small EC2 instances and small load, ARM CPUs show less impressive performance. So we can’t see its benefits comparing with Intel EC2
3. Intel is still the leader in the area of low-concurrency scenarios. And it is definitely winning on EC2 with a small amount of vCPU.
4. AMD does not show any competitive results in all cases.   

Final Thoughts

1. AMD — we have a lot of questions about EC2 instances on AMD. So it would be a good idea to check what was going on that EC2 during the test and check the general performance of CPUs on those EC2.
2. We found out that in some specific conditions, Intel and Graviton could compete with each other. But the other side of the coin is economical. What is cheaper to use in each situation? The next article will be about it. 
3. It would be a good idea to try to use EC2 with Graviton for real high-concurrency DB.  
4. It seems it needs to run some additional scenarios with 256 and 512 threads to check the hypothesis that Graviton could work better when threads are more than vCPU.

Check out part two of our tests!

 

APPENDIX:

List of EC2 used in research:

CPU type	EC2	EC2 price per hour (USD)	vCPU	RAM
Graviton	m6g.large	0.077	2	8 Gb
Graviton	m6g.xlarge	0.154	4	16 Gb
Graviton	m6g.2xlarge	0.308	8	32 Gb
Graviton	m6g.4xlarge	0.616	16	64 Gb
Graviton	m6g.8xlarge	1.232	32	128 Gb
Graviton	m6g.12xlarge	1.848	48	192 Gb
Graviton	m6g.16xlarge	2.464	64	256 Gb
Intel	m5.large	0.096	2	8 Gb
Intel	m5.xlarge	0.192	4	16 Gb
Intel	m5.2xlarge	0.384	8	32 Gb
Intel	m5.4xlarge	0.768	16	64 Gb
Intel	m5.8xlarge	1.536	32	128 Gb
Intel	m5.12xlarge	2.304	48	192 Gb
Intel	m5.16xlarge	3.072	64	256 Gb
AMD	m5a.large	0.086	2	8 Gb
AMD	m5a.xlarge	0.172	4	16 Gb
AMD	m5a.2xlarge	0.344	8	32 Gb
AMD	m5a.4xlarge	0.688	16	64 Gb
AMD	m5a.8xlarge	1.376	32	128 Gb
AMD	m5a.12xlarge	2.064	48	192 Gb
AMD	m5a.16xlarge	2.752	64	256 Gb

 

my.cnf