EmergencyEMERGENCY? Get 24/7 Help Now!

20-30% Performance Hit from the Spectre Bug Fix on Ubuntu

 | January 23, 2018 |  Posted In: Insight for DBAs, Insight for Developers, MySQL, Security

PREVIOUS POST
NEXT POST

Spectre Bug Fix on UbuntuIn this blog post, we’ll look at the performance hit from the Spectre bug fix on Ubuntu.

Recently we measured the performance penalty from the Meltdown fix on Ubuntu servers. It turned out to be negligible.

Today, Ubuntu made a Spectre bug fix on Ubuntu available, shipped in kernel 4.4.0-112. As with the Meltdown fix, we measured the effect of this update. Unfortunately, we observed a major performance penalty on MySQL workloads with this new kernel.

Our benchmark used the following:

System:

  • CPU:
    • 2 x Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz (Codename Haswell)
    • /proc/cpuinfo has 48 entries
  • Server
    • Supermicro Motherboard X10DRI
  • Storage
    • NVMi Intel DC 36000
  • Ubuntu 16.04
    • no-fix – kernel 4.4.0-104-generic
    • fix (now GA) – kernel 4.4.0-112-generic

With the fix, the Spectre and Meltdown mitigation detection tool v0.27 reports following:

Workload:

  • sysbench 1.0.11 oltp_read_only and oltp_point_select
  • 32 tables, 10mln rows each
  • datasize ~73GB

Server:

Sysbench script:

The results

The results are in transactions per sec (more is better).

In memory (buffer pool 100G)

Connection via TCP

bp workload threads tps no-fix tps fix ratio no-fix/fix
100 oltp_read_only 1 810.76 655.34 1.24
100 oltp_read_only 2 1589.66 1277.02 1.24
100 oltp_read_only 8 6233.69 5018.11 1.24
100 oltp_read_only 16 11253.28 9477.18 1.19
100 oltp_read_only 64 22702.29 18564.30 1.22
100 oltp_read_only 128 22281.22 18357.06 1.21
100 oltp_point_select 1 16095.32 12380.20 1.30
100 oltp_point_select 2 32665.97 24907.84 1.31
100 oltp_point_select 8 132480.34 101787.44 1.30
100 oltp_point_select 16 236832.94 189087.10 1.25
100 oltp_point_select 64 498322.41 415631.91 1.20
100 oltp_point_select 128 496661.65 414495.64 1.20

Buffer pool 50G

Connection via TCP

bp workload threads tps no-fix tps fix ratio no-fix/fix
50 oltp_read_only 1 683.09 595.63 1.15
50 oltp_read_only 2 1390.70 1143.30 1.22
50 oltp_read_only 8 5262.02 4493.87 1.17
50 oltp_read_only 16 9842.04 8242.02 1.19
50 oltp_read_only 64 21021.20 17644.76 1.19
50 oltp_read_only 128 21526.21 17932.34 1.20
50 oltp_point_select 1 14535.73 11758.57 1.24
50 oltp_point_select 2 28721.43 23277.60 1.23
50 oltp_point_select 8 108422.96 90189.94 1.20
50 oltp_point_select 16 203876.31 167382.92 1.22
50 oltp_point_select 64 447757.48 376506.97 1.19
50 oltp_point_select 128 473894.73 384301.33 1.23

Buffer pool 25G

connection via TCP

bp workload threads tps no-fix tps fix ratio no-fix/fix
25 oltp_read_only 1 542.09 470.88 1.15
25 oltp_read_only 2 1074.54 931.02 1.15
25 oltp_read_only 8 4169.10 3621.79 1.15
25 oltp_read_only 16 7626.30 6716.29 1.14
25 oltp_read_only 64 18206.18 15702.90 1.16
25 oltp_read_only 128 20224.22 16966.13 1.19
25 oltp_point_select 1 11107.73 9294.73 1.20
25 oltp_point_select 2 22486.65 18526.84 1.21
25 oltp_point_select 8 86385.70 73226.44 1.18
25 oltp_point_select 16 161409.65 135689.48 1.19
25 oltp_point_select 64 370809.49 320848.79 1.16
25 oltp_point_select 128 433324.54 358947.61 1.21

 

We can see that in CPU-bound workloads the overhead is 20-25%, reaching up to 30% in point select queries. In IO-bound (25G buffer pool) workloads, the observed overhead is 15-20%.

This is a major performance hit, and you should consider it carefully before upgrading to the new kernel.

One hope that is retpoline kernels will have much less impact.

PREVIOUS POST
NEXT POST
Vadim Tkachenko

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks. Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products. He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.

5 Comments

  • Vadim – thanks for sharing these results. Do you have any AMD-based server hardware to see if AMD CPUs are also affected as much as Intel CPUs?

  • The performance hit relates to the generation of the Intel CPU.
    In this case, the title should be that the performance hit relates to E5-2680 CPU (released in 2012, EOL since 2015).

    • The used CPU is E5-2680 v3, notice the V3 at the end.
      Launched in Q3’14 and is not EOL.

      Non the less, I’d like some Skylake benchmarks. There are stories that Skylake and newer generations have a smaller performance hit.

  • I don’t know if it’s related, but I have found a similar performance hit on AMD Ryzen with Sybase SQLAnywhere Database. Doing a large insert from a select was about 20% slower on patched Ubuntu 16.04 compared with unpatched 14.04. However, the really strange result was that execution of a dbbackup command (which runs an ancient single-threaded Java app to capture pages to a backup file) was about 10 times slower! I suspect that says more about the way in which that code was written than is generally useful.

Leave a Reply