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

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

bpworkloadthreadstps no-fixtps fixratio no-fix/fix
100oltp_read_only1810.76655.341.24
100oltp_read_only21589.661277.021.24
100oltp_read_only86233.695018.111.24
100oltp_read_only1611253.289477.181.19
100oltp_read_only6422702.2918564.301.22
100oltp_read_only12822281.2218357.061.21
100oltp_point_select116095.3212380.201.30
100oltp_point_select232665.9724907.841.31
100oltp_point_select8132480.34101787.441.30
100oltp_point_select16236832.94189087.101.25
100oltp_point_select64498322.41415631.911.20
100oltp_point_select128496661.65414495.641.20

Buffer pool 50G

Connection via TCP

bpworkloadthreadstps no-fixtps fixratio no-fix/fix
50oltp_read_only1683.09595.631.15
50oltp_read_only21390.701143.301.22
50oltp_read_only85262.024493.871.17
50oltp_read_only169842.048242.021.19
50oltp_read_only6421021.2017644.761.19
50oltp_read_only12821526.2117932.341.20
50oltp_point_select114535.7311758.571.24
50oltp_point_select228721.4323277.601.23
50oltp_point_select8108422.9690189.941.20
50oltp_point_select16203876.31167382.921.22
50oltp_point_select64447757.48376506.971.19
50oltp_point_select128473894.73384301.331.23

Buffer pool 25G

connection via TCP

bpworkloadthreadstps no-fixtps fixratio no-fix/fix
25oltp_read_only1542.09470.881.15
25oltp_read_only21074.54931.021.15
25oltp_read_only84169.103621.791.15
25oltp_read_only167626.306716.291.14
25oltp_read_only6418206.1815702.901.16
25oltp_read_only12820224.2216966.131.19
25oltp_point_select111107.739294.731.20
25oltp_point_select222486.6518526.841.21
25oltp_point_select886385.7073226.441.18
25oltp_point_select16161409.65135689.481.19
25oltp_point_select64370809.49320848.791.16
25oltp_point_select128433324.54358947.611.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.

Share this post

Comments (5)

  • John Cagle Reply

    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?

    January 23, 2018 at 9:43 pm
  • Vadim Tkachenko Reply

    John,

    I do not have modern AMD servers on my hands right now

    January 24, 2018 at 11:59 am
  • Mike Ruffle Reply

    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).

    January 26, 2018 at 5:55 am
    • Gijs Reply

      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.

      January 26, 2018 at 8:17 am
  • thewinelake Reply

    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.

    January 26, 2018 at 11:06 am

Leave a Reply