Does the Meltdown Fix Affect Performance for MySQL on Bare Metal?

In this blog post, we’ll look at does the Meltdown fix affect performance for MySQL on bare metal servers.

Since the news about the Meltdown bug, there were a lot of reports on the performance hit from proposed fixes. We have looked at how the fix affects MySQL (Percona Server for MySQL) under a sysbench workload.

In this case, we used bare metal boxes with the following specifications:

• Two-socket Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz (in total 56 entries in /proc/cpuinfo)
• Ubuntu 16.04
• Memory: 256GB
• Storage: Samsung SM863 1.9TB SATA SSD
• Percona Server for MySQL 5.7.20
• Kernel (vulnerable) 4.13.0-21
• Kernel (with Meltdown fix) 4.13.0-25

Please note, the current kernel for Ubuntu 16.04 contains only a Meltdown fix, and not one for Spectre.

We performed the validation with the https://github.com/speed47/spectre-meltdown-checker tool. The database size is 100GB in a sysbench workload with 100 tables, 4mln rows each with Pareto distribution.

We have used a socket connection and TCP host connection to measure a possible overhead from the TCP network connection. We also perform read-write and read-only benchmarks.

The results are below for a various number of threads:

Where

• Nokpti: kernel without KPTI patch (4.13.0-21)
• Pti: kernel with KPTI patch (4.13.0-25), with PTI enabled
• Nopti: kernel with KPTI patch (4.13.0-25), with PTI disabled

 

 

As you can see, there is very little difference between runs (in 3-4% range), which fits into variance during the test.

Similar experiments were done on different servers and workloads:

• https://github.com/Percona-Lab-results/201701-meltdown-OLTP-ro/blob/master/smperf-ubuntu-results.md
• https://github.com/Percona-Lab-results/201701-meltdown-OLTP-ro/blob/master/centos-res.md

There also we see a negligible difference that fits into measurement variance.

Overhead analysis

To understand why we do not see much effect in MySQL (InnoDB workloads), let’s take a look where we expect to see the overhead from the proposed fix.

The main overhead is expected from a system call, so let’s test syscall execution on the kernel before the fix and after the fix (thanks for Alexey Kopytov for an idea how to test it with sysbench).

We will use the following script syscall.lua:

Basically, we measure the time for executing 10000 system calls (this will be one event).

To run benchmark: sysbench syscall.lua --time=60 --report-interval=1 run 

And the results are following:

• On the kernel without the fix (4.13.0-21): 455 events/sec
• On the kernel with the fix (4.13.0-26): 250 events/sec

This means that time to execute 10000 system calls increased from 2.197ms to 4ms.

While this increase looks significant, it does not have much effect on MySQL (InnoDB engine). In MySQL, you can expect most system calls done for IO or network communication.

We can assume that the time to execute 10000 IO events on the fast storage takes 1000ms, so adding an extra 2ms for the system calls corresponds to adding 0.2% in overhead (which is practically invisible in MySQL workloads).

I expect the effect will be much more visible if we work with MyISAM tables cached in OS memory. In this case, the syscall overhead would be much more visible when accessing data in memory.

Conclusion:

From our results, we do not see a measurable effect from KPTI patches (to mitigate the Meltdown vulnerability) running on bare metal servers with Ubuntu 16.04 and 4.13 kernel series.

Reference commands and configs:

RW:

mysqld:
Percona Server 5.7.20-19

My.cnf file: