MySQL on x86 vs ARM

作者: Krunal Bauskar

By and large this would be a topic of interest for most of us including me when I started to explore this space. Before we dwell into the numbers let’s first understand some basic differences between 2 architectures. Beyond being CISC and RISC let’s look at the important differences from MySQL perspective.

• Strong vs Weak memory model (weak memory model needs proper memory barrier while writing lock-free code).
• Underlying hardware specific specialized instructions. For example: both now support crc32c hardware instructions but being low-level they are different ways to invoke them. For more differences checkout for x86-SSE/ARM-ACLE.
• Cache Line differences. Most of the ARM processors tend to use bigger cache lines (128 bytes for all caches or a mix of 64/128 bytes).
• Other sys-call level differences like: absence of PAUSE instructions with ARM and substitute instruction with very low latency failing to induce needed delay, sched_getcpu is costlier on ARM introducing challenges with use of lock-free construct, memory operations seems to show higher latency, etc…

Community has contributed multiple patches around this space (Topic for another blog). Since MySQL just started supporting MySQL on ARM there are few optimizations but most of the work is yet to be done.

Performance

Now let’s look at the most important aspect: Performance

We tested the performance of MySQL (current release 8.0.19) on x86 and ARM. Details of the test and machine are given below.

Test Setup

• 24 vCPU/48 GB Intel(R) Xeon(R) Gold 6266C CPU @ 3.00GHz for running MySQL on x86.
• 24 vCPU/48 GB ARM @ 2.60GHz for running MySQL on ARM
• sysbench is running on a dedicated machine located in the same data-center.
• sysbench steps:
  • Load Tables. (Same seed db is reused for multiple runs so warmup is needed).
  • Checksum based warmup. Run checksum on all tables. For checksum, flow needs to fetch the rows in the buffer pool there-by causing it to warm up.
  • Query based warm up. Can skip but helpful if you are using adaptive hash indexes.
  • Execute TC (oltp-read-write/oltp-update-index/oltp-update-non-index/oltp-read-only/oltp-point-select)
  • Each TC is executed for N different scalability. Given 24 vCPU tried it for 1/2/4/8/16/32/128/256.
  • Before switching TC, an intermediate sleep is introduced to help flush changes from previous TC. This can’t ensure all changes are flushed but sleep of X secs ensures least impact on followup TC.
  • MySQL-Server Configuration:
    • BP is large enough to accomodate complete data in-memory
    • For more details please check the following configuration details

Run specific details:

• Table: 96-tables * 1.5 million (data-size= 34GB)
• Buffer Pool: 36GB
• Redo-Log: 4GB*2
• TC-run-time: 300 secs
• TC-warmup: 60 (sysbench –warmup-time)
• workload-query-based warmup: 600
• change-over-sleep: 180
• checksum-based-warmup: enabled
• data-storage: 300GB (support for 16500 IOPS (nullify effect of Burst IOPS)).

Note: Frequency Scaling (FS). Given ARM is running @ 2.6 GHz vs x86 is running @ 3.0 GHz. Comparing them directly is not fair. In order to compensate for the frequency difference, graphs also add frequency-scaled tps/qps for ARM (ARM-fscaled simply extrapolate original ARM tps/qps number by (3/2.6) factor). In real life, the factor could be a bit on the higher side given increasing CPU frequency can affect contention graphs and wait cycles.

1. Point Select:

Analysis:

• ARM performs better than x86 for lower scalability but fails to scale at same rate with increasing scalability.
• With frequency scaling applied ARM continues to beat x86 despite of the scalability issues.

2. Read Only:

Analysis:

• ARM is almost on par with x86 for lower scalability but again fails to scale for higher scalability.
• With frequency scaling applied ARM continues to beat x86 (in most cases).

3. Read Write:

Analysis:

• Pattern is different with read-write workload. ARM starts lagging. Frequency scaling helps ease this lag for lower scalability but increasing scalability continues to increase the gap.

4. Update Index:

Analysis:

• Frequency scaled ARM continues to perform on par/better with x86 (except for heavy contention use-cases).

5. Update Non-Index:

Analysis:

• Frequency scaled ARM continues to perform on par/better with x86 (except for heavy contention use-cases).

Conclusion

There are some important observations we can make:

• For read only workload MySQL on ARM continues to perform on-par with MySQL on x86.
• For write involving workload MySQL on ARM starts lagging a bit but if we consider frequency scaling things start getting better.
• Frequency scaling is not a real life parameter so we should consider the price-per-performance ratio. This could be a topic in itself but just a quick fact: ARM instance is 66% cheaper than x86 (24U48G same one we used).
• There is a pattern that we can observe. ARM workloads are very well scalable till it hits the CPU limits. With increasing scalability, contention increases and ARM starts lagging. This is expected since mutexes/contention hot-spots were all tuned for x86 (for example: spin-lock). But now that MySQL officially supports ARM and the growing ARM community and interest, it would be tuned for ARM too.

To summarize, MySQL on ARM is a worth exploring option from a cost and performance perspective.