How Binary Logs Affect MySQL 8.0 Performance

As part of my benchmarks of binary logs, I’ve decided to check how the recently released MySQL 8.0 performance is affected in similar scenarios, especially as binary logs are enabled by default. It is also interesting to check how MySQL 8.0 performs against the claimed performance improvements in redo logs subsystem.

I will use a similar setup as in my last blog with MySQL 8.0, using the utf8mb4 charset.

I have a few words about MySQL 8.0 tuning. Dimitri’s recommends in his blog posts using innodb_undo_log_truncate=off and innodb_doublewrite=0. However, in my opinion, using these setting are the same as participating in a car race without working breaks: you will drive very fast, but it will end badly. So, contrary to Dimitri’s recommendations I used innodb_undo_log_truncate=on and innodb_doublewrite=1.

Servers Comparison

For the first run, let’s check the results without binary logs vs. with binary logs enabled, but with sync_binlog=1 for Percona Server for MySQL 5.7 vs. MySQL 8.0.


MySQL 8.0 Performance

In tabular form:

Binary logBuffer pool, GBMYSQL8PS57Ratio PS57/MySQL8
binlog5768.0375771.55321.00
binlog101224.5351245.4961.02
binlog201597.481625.1531.02
binlog301859.6031979.3281.06
binlog402164.3292388.8041.10
binlog502572.8272942.0821.14
binlog603158.4083528.7911.12
binlog703883.2754535.2811.17
binlog804390.695246.5671.19
nobinlog5788.9388783.1550.99
nobinlog101290.0351294.0981.00
nobinlog201745.4641743.7591.00
nobinlog302109.3012158.2671.02
nobinlog402508.282649.6951.06
nobinlog503061.1963334.7661.09
nobinlog603841.924168.0891.08
nobinlog704772.7475140.3161.08
nobinlog805727.7955947.8481.04

 

Binary Log Effect

MySQL 8.0 Performance 2

In tabular form:

Buffer pool, GBserverbinlognobinlogRatio nobinlog / binlog
5MYSQL8768.0375788.93881.03
5PS57771.5532783.1551.02
10MYSQL81224.5351290.03521.05
10PS571245.4961294.09831.04
20MYSQL81597.481745.46371.09
20PS571625.1531743.75861.07
30MYSQL81859.6032109.30051.13
30PS571979.3282158.26681.09
40MYSQL82164.3292508.27991.16
40PS572388.8042649.69451.11
50MYSQL82572.8273061.19561.19
50PS572942.0823334.76561.13
60MYSQL83158.4083841.92031.22
60PS573528.7914168.08861.18
70MYSQL83883.2754772.74661.23
70PS574535.2815140.3161.13
80MYSQL84390.695727.7951.30
80PS575246.5675947.84771.13

 

Conclusions

It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.

In general, for in-memory workloads, Percona Server for MySQL 5.7 outperforms MySQL 8.0 by 10-20% with binary logs enabled, and 4-9% without binary logs enabled.

For io-bound workloads (buffer pool size <= 30GB), the performance numbers for Percona Server for MySQL and MySQL are practically identical.

Hardware spec

Supermicro server:

  • Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz
  • 2 sockets / 28 cores / 56 threads
  • Memory: 256GB of RAM
  • Storage: SAMSUNG  SM863 1.9TB Enterprise SSD
  • Filesystem: ext4/xfs
  • Percona-Server-5.7.21-20
  • OS: Ubuntu 16.04.4, kernel 4.13.0-36-generic

Extra Raw Results, Scripts and Config

My goal is to provide fully repeatable benchmarks. I have shared all scripts and settings I used in the following GitHub repo:

https://github.com/Percona-Lab-results/201805-sysbench-tpcc-mysql8

 

Share this post

Comments (3)

  • Agnus Reply

    What is the main idea/trick to boost MySQL binary logging performance?

    May 7, 2018 at 5:10 am
    • Chesler E. Reply

      The common knowledge is https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_sync_binlog

      sync_binlog = 0 # fast but the binary log is never synchronized to disk, and the server relies on the operating system to flush the binary log’s contents from time to time as for any other file. not safe

      sync_binlog = >1 # this number of binary log commit groups is periodically synchronized to disk.

      Using sync_binlog != 1 transactions are committed without having been synchronized to disk.

      In the event of a power failure or operating system crash, it is possible that the server has committed some transactions that have not been synchronized to the binary log. Therefore it is impossible for the recovery routine to recover these transactions and they will be lost from the binary log.

      May 8, 2018 at 3:59 am
  • Mark Callaghan Reply

    One result from sync_binlog=X where X>1 is more variance for the one commit stuck forcing the binlog on behalf of the previous X-1 commits. So you get less variance on that fsync, but it is more frequent. Maybe that helps the p99 metrics on the benchmark, but it seems like we are playing a game.

    May 8, 2018 at 5:29 pm

Leave a Reply