« MySQL Performance : 8.0 and Sysbench OLTP_RW / Update-NoKEY | Main | MySQL Performance : 1M *IO-bound* QPS with 8.0 GA on Intel Optane SSD ! »
Wednesday, 09 May, 2018
MySQL Performance : 8.0 RW & Binlog impact
In the
previous article I've intentionally skipped the topic related to
Binlog impact on MySQL 8.0 Performance because it's not a short story,
nor a simple one..
In fact, for most of people Binlog in MySQL is
generally representing an additional overhead, and historically it was
true. Since MySQL 5.6 there is Binlog Group Commit (BGC) feature
available, and it was rather doing well, decreasing
the gap between "binlog=OFF" and "binlog=ON sync_bin=1". However,
storage vendors are making flash drives more and more faster (and
cheaper) from year to year.. And when we delivered MySQL 5.7 the scope
of Binlog impact moved with code and flash storage improvements -- the
main impact was no more coming from the I/O operations related to
Binlog, but from the Binlog code itself ! -- indeed, this may sound odd
initially, but let's go to "pictures" to see it better in details ;-))
So
far, I'll reuse the same Skylake server as before, but will reduce it to
1S (1CPU Socket, 24cores-HT) -- so, you don't believe it's all because
I'm using a "big HW" (while 2S HW is the most common server config today
in all data centers where people are running MySQL, and having
16-24cores per CPU Socket is what is todays "commodity HW") -- but well,
let's stay with 24cores-HT for the following experiment ;-)) And as the
storage it'll be the same Optane drive with EXT4 filesystem.
I'll
now replay the same Sysbench OLTP_RW and Update-NoKEY tests as before,
but using only 1S (24cores-HT) and with the same previous my.conf but
with 4 additional variations :
- 1) binlog=OFF
- 2) binlog=ON sync_bin=0
- 3) binlog=ON sync_bin=1000
- 4) binlog=ON sync_bin=1
Sysbench OLTP_RW 10Mx8-tables @MySQL-5.7
Comments :
- as you can see, on a higher load enabling Binlog is helping a higher TPS !
- (well, in fact it's helping not to gain, but rather not to loose TPS on high load)
- but in any case, you're seeing here a positive impact ! ;-))
- and you can understand that in such a case it was difficult to blame Binlog code along MySQL 5.7 time ;-))
Specially that even more important "positive impact" happens on much more aggressive writes with Update-NoKey workload :
Sysbench Update-NoKey 10Mx8-tables @MySQL-5.7
Comments :
- as you can see, enabling Binlog is helping a lot MySQL 5.7 to not loose performance on high load..
- and this is all because it helps to "hide" the REDO log contention we have in 5.7
And it helped well, until we did not improve the whole REDO log code in MySQL 8.0 ;-)) -- since then the same story is looking completely different now :
Sysbench OLTP_RW 10Mx8-tables @MySQL-8.0
Comments :
- only negative impact from Binlog in MySQL 8.0
- and 20K TPS instead of 25K TPS is a pretty huge difference..
Sysbench Update-NoKey 10Mx8-tables @MySQL-8.0
Comments :
- but since the Writes are more aggressive in your workload, the impact then is even more dramatic..
- more that x2 times TPS drop..
In case you're still suspecting the above is only valid for Skylake & Optane, here are the similar results from 1S Broadwell 22cores-HT and other vendor flash drive :
MySQL 5.7 :
MySQL 8.0 :
This is the reason why Binlog stuff in MySQL 8.0 must be fixed asap, and I really hope it'll happen soon ! -- seems like the whole story around Binlog must be re-visited and re-implemented..
BTW, if you have a patch, you're more than welcome ! ;-))
Rgds,
-Dimitri
blog comments powered by DisqusNote: if you don't see any "comment" dialog above, try to access this page with another web browser, or google for known issues on your browser and DISQUS..