I am in the process of upgrading my home NUC cluster from Ubuntu 18.04 to 20.04 and that means I get to use newer versions of gcc. It also means I lose easy access to older versions of gcc. I assumed that I wouldn't be able build MyRocks and MySQL 5.6 from source in Ubuntu 20.04 but I never confirmed it and I might be wrong. I have been using gcc 7 on Ubuntu 18.04 which is still available in 20.04, if I am willing to manage multiple versions of gcc. Regardless it is time for me to begin using MyRocks with MySQL 8.
I have results for the insert benchmark to compare MySQL 5.6 and 8.0 where both use MyRocks and the results are what I expected -- I lose between 10% and 20% of throughput (queries or inserts /second) because 8.0 has more CPU overhead. Note that this is for a workload with low-concurrency and my NUC servers have 4 cores with HT disabled. This is similar to what I see when comparing InnoDB between MySQL 5.6 and 8.0. I prefer no new overhead, but new overhead is inevitable and the amounts here seem reasonable given these are two versions apart -- 5.6 to 5.7 to 8.0.
Update - the numbers above include the CPU from the benchmark client and mysqld that share the same host. When I limit the CPU measurement to mysqld then the difference is 1.4X during load without secondary indexes, that is mysqld in MySQL 8.0 uses 1.4X more CPU to do the same amount of work during the load. While I am OK with 1.2X more CPU (~20% mentioned above) I think that 1.4X more is too much.
Background reading that has more detail:
- Details on my home NUC cluster
- Notes on the insert benchmark and an update on how I run it
- Notes on building MyRocks for MySQL 8
- l.i0 - load without secondary indexes
- l.x - create secondary indexes
- l.i1 - load with secondary indexes
- qN.2 - read+write where N is the number of inserts/s
Was 8 running on defaults? Because "From MySQL 8.0, binary logging is enabled by default": https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html
ReplyDeleteBinlog was enabled, but binlog fsync and InnoDB redo fsync were disabled because I don't want this to be an fsync benchmark. The my.cnf contents are linked above.
DeleteHow did you disable the InnoDB redo fsync()?
ReplyDeleteStill runs about once/second in the background but not per/commit in the foreground. As I wrote above, I provided a link to the my.cnf that has all the detail.
Delete