Benchmarking the new Arm-powered M6g instances from AWS

Note: Although I work for AWS, these are my own personal findings and thoughts. Please do not consider them as official benchmarks in any way!

AWS announced the latest M6g instances in December 2019. These feature Arm-powered Graviton2 processors, as well as fully encrypted DDR4 memory. Arm processors are everywhere in terms of mobile devices, and my favourite Raspberry Pi computers, but have not traditionally been featured within the cloud. This is changing.

Arm-powered processors are not new to AWS: The first iteration (a1) was announced in November 2018.

Why would you care? In short, the announcements claim that you will see similar (or better!) performance to comparable Intel hardware, for a lower cost. What’s the catch? Your workloads have to be compatible with an Arm architecture. Chances are, if you are running standard Linux workloads on a popular distribution (e.g. Amazon Linux or Ubuntu), these are going to be a real option for you.

With M6g now Generally Available, I decided to take a closer look for myself. How easy would it be to get going? What peformance would I find?

Getting up and running

For a head-to-head comparison, I decided to go with the following instances:

  • m5.xlarge (Intel 4 VPUs, 16 gig RAM, $0.214 per hour On Demand)
  • m6g.xlarge (Graviton2 4 VPUs, 16 gig RAM, $0.172 per hour On Demand)

The above prices were correct at the time of writing for the eu-west-1 (Ireland) region. At launch, the m6g instances are also available in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), and Asia Pacific (Tokyo).

This article assumes that you are already familiar with spinning up Linux instances within AWS, including ssh access once they are available. If you need it, here’s the official Getting Started Guide.

Secondly, these instances are not Free Tier eligible! You will be incurring costs by spinning them up. Please remember to tidy up after yourself afterwards!

You know you are in the right place when, after electing to launch a new instance from the EC2 console, you see this:

Yes, the choice of either x86 or Arm architectures!

For this exercise, I went with Ubuntu Server 18.04 LTS. As some of the benchmarks are storage heavy, I changed the root EBS volumes to be 30 gigabytes in size, but still the default gp2 SSD storage.

I was then able to ssh in to start the benchmarking. The process for each instance was identical. Ubuntu looks and operates just the same, whether you are using the x86 or Arm editions. In fact, I would check /proc/cpuinfo every so often as a sanity check to ensure I was logged into the right machine at times (!)

1. Linux kernel compilation

Ah, that old favourite! Let’s grab the latest Linux kernel and see how each machine does at compiling it!

Here are the commands to invoke:

Some notes on the above:

  1. After running make menuconfig, simply Exit and save the default settings.
  2. We use -j 4 for the make process to use all 4 available CPU cores for the building process.

The results?

m5.xlarge33 minutes, 43 seconds (2023 seconds)
m6g.xlarge34 minutes, 29 seconds (2069 seconds)

In this test, the Arm system was 2.25% slower. That’s pretty close. Especially when you consider it is 21.7% cheaper in On Demand costs!

There’s a slight caveat with this test: The exact files compiled could vary between x86 and Arm architectures. It’s not exactly scientific. So let’s move on to some more…. traditional…. benchmarking.

2. MariaDB performance

For benchmarking exercise number 2, it was the turn of MariaDB. As a quick reminder:

MariaDB Server is one of the most popular open source relational databases. It’s made by the original developers of MySQL and guaranteed to stay open source. It is part of most cloud offerings and the default in most Linux distributions.

{{< figure src=”mariadb-logo.png” >}}

Here, I combine installing MariaDB as well as sysbench in order to load test it. A read / write test is performed. Here we go!

Some caveats here:

  1. This is the test that is very hungry on disk space. Most of the 30 gigabyte storage will be utilised.
  2. You will notice I don’t secure the MySQL instance, with the commands running as root. This is not Best Practice for general systems. However, in this case the instances are disposable, and they are being destroyed after the testing process.

The results?



If we pull out the key performance metrics:

| Instance | Metric | Result |
| m5.xlarge | Transactions | 103.91 / second |
| | Queries | 5819.10 / second |
| m6g.xlarge | Transactions | 107.56 / second |
| | Queries | 6023.09 / second |

Here, the Arm-powered m6g instance was 3.45% faster for both Transactions and Queries. Decent! And, again, still 21.7% cheaper!

3. Redis performance

Finally, it was the turn of Redis.

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs, geospatial indexes with radius queries and streams.

I was particularly interested in this one: It’s in-memory. Would there be a performance impact with the full encryption of RAM involved with the Graviton2 processors?

This one is nice and easy to do:

The results:



There are a lot of stats here, so just pulling out a few:

| Instance | Metric | Result |
| m5.xlarge | SET | 101,522 / second |
| | GET | 100,908 / second |
| m6g.xlarge | SET | 135,318 / second |
| | GET | 132,100 / second |

A big difference here! The Arm-equipped ms6.xlarge is 26.7 – 28.5% faster on these metrics. In fact, it’s faster on all of them, except the latter two LRANGE tests. That could be worth looking deeper into.


From these tests, my conclusion is that the m6g.xlarge is punching very well in terms of performance, in comparison to the m5.xlarge. It was ever-so-slightly slower on the Linux kernel compilation, ever-so-slightly faster on the MariaDB tests, and notably faster on the Redis tests.

Then we factor in the price. The m6g.xlarge It’s 21.7% cheaper in terms of On Demand pricing!

I would definitely be looking to move any appropriate Linux workloads to the Graviton2 setup. The price / performance ratio is stellar here. I can see these processors becoming increasingly popular as ‘word gets out’ on just how good the ratio is!

I hope you have found this journey into some very simple benchmarks useful. I’d be very interested to hear on any workloads you are considering moving to Graviton – perhaps you’ve already moved them!

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top