Wednesday, 29 October, 2014
Percona Live London 2014 is starting next week and I'm happy to speak there about MySQL 5.7 Performance, Scalability & Benchmarks latest news. Indeed, MySQL 5.7 has a lot of positive changes and impressive improvements. And, looking on MySQL 5.7 Performance, there are many cases where the gap comparing to MySQL 5.6 today is simply amazing! ;-) -- but, of course, there are still some pending issues which are requiring yet more work to reach the expected speed-up.. So, I'll tell you all about the most hot stories around, while I'm also always curious about your issues you're hitting on your production systems. Please, don't hesitate to share them - this is helping us to make MySQL yet more better! ;-)
Wednesday, 08 October, 2014
This is the next part of the stories about MySQL 5.7 Performance..
So far, the previous story was about reaching 645K QPS with SQL queries, while in reality it's only a half of the full story ;-) -- because when last year we've reached 500K QPS due a huge improvement on the TRX-list code, the same improvement made a negative impact on the all single-table test workloads..
What happened finally :
- the new code changes dramatically lowered contention on TRX-list (trx_sys mutex)
- which is made MDL related locking much more hot..
- and if one table becomes hot on a workload, MDL lock contention then is hitting its highest level..
So far, it was clear that MDL is needed a fix. Specially seeing that on 8-tables workload we're reaching 645K QPS. However there was a dilemma: should we push the TRX-list change to the 5.7 code, or wait first for MDL improvement?.. -- and we finally decided to push the changes, even if for some period of time we'll need to accept a regression on all single-table workload..
So, what we got the last year :
- 500K QPS on 8-tables point-select
- less than 200K QPS on 1-table.. - which was even worse than in MySQL 5.6 ;-)
It was clear, we have to fix MDL code asap, but the MDL story was not that simple either :
- Dmitry Lenev made a quick dirty patch just removing completely all MDL related code from the source tree..
- so, of course, we all expected to see a huge QPS jump after that on this experimental code, right? ;-)
- however, for our big surprise, QPS just remained on exactly the same level...
- what is going odd?..
- in fact instead of the MDL contention we moved to the THR_lock mutex contention!
- what is interesting that until the MDL code is present, we don't see any sign of THR_lock ;-)
- and it's only since MDL is no more here -- THR_lock is firing!..
- finally Dmitry made another dirty patch removing all THR_lock related code too..
- and bingo! - without MDL & THR_lock code we doubled QPS at once, and it became clear that both contentions should be fixed to bring a speed-up on single-table workloads...
All my kudos here to Dmitry Lenev, who worked very hard to find the most optimal solution to fix both problems. There were several prototypes, less or more successful, until the final solution out-passed all our expectations -- just because it provided us the same QPS level as the binary which has no MDL nor THR_lock code at all!!! - and this is awesome! ;-))
I was happy to follow all this work very closely and play with each new update. Let me show you now just a short "making off" which is representing pretty well a summary of the one step in the progress in this work:
there are 4 tests running the same OLTP_RO point-select workload on
8/16/32..1024 users :
- #1 is using the original 5.7 code
- #2 is using #1 + MDL fix
- #3 is using #2 + removed THR_lock code
#4 is using #1 + removed MDL code + removed THR_lock code
- as you can see, the original code (#1) is suffering of MDL rwlock contention and not out-passing 200K QPS..
- the MDL fix in #2 is helping little bit to reach more than 200K QPS, but then the THR_lock mutex contention is killing an overall performance..
- by removing completely the THR_lock code (#3) we can see the potential level of performance we should have if THR_lock contention was also fixed
- then in #4 we can see the QPS level on 5.7 if there was no MDL & THR_lock code at all..
- and what remarkable here that #3 and #4 are showing exactly the same performance!
- so, the MDL fix worked extremely well to run as efficiently as if MDL code was removed ;-)
- the next step was to do the same with THR_lock to get the solution simply perfect! ;-)
- and it's exactly what was done finally in 5.7 and can be seen now in DMR5..
May only say kudos MySQL Runtime Team! kudos Dmitry Lenev!!! ;-))
Let me show you now the final impact of all these changes (and keep in mind that just a year ago the MySQL 5.7 results here were worse on all the following tests comparing to MySQL 5.6)..
Sysbench OLTP_RO 1-table 10M :
Sysbench OLTP_RO Point-Selects 1-table 10M :
Sysbench OLTP_RO Simple-Ranges 1-table 10M :
Sysbench OLTP_RW 1-table 10M trx2 :
Sysbench OLTP_RW 1-table 10M trx1 :
As you can see, the same performance improvement we can see on OLTP_RW workloads as well, where :
- trx2 : means innodb_flush_log_at_trx_commit=2
- trx1 : means innodb_flush_log_at_trx_commit=1
to be continued..
Tuesday, 07 October, 2014
And I'm not saying this because I'm MySQL/Oracle employee ;-)) - just
expressing my personal feeling while flying back to Paris..
I really enjoyed this conference now much more than all previous years :
first of all having 5 days instead of 2 allows to have much more
networking than before (and usually it's the main goal for every
conference to create a lot of informal discussions and exchange on
then, the content - all excellent, no words.. there was so much new
stuff to discover and learn from other experiences, that I'm pretty
sure that each person at one moment during the conference should feel
a kind of "brain overflow" ;-) and what is good that there were talks
for any levels of skills -- so, it was very easy to progress on
understanding of each topic quickly and smoothly..
organization was just perfect : all in one place, no more running over
different floors/buildings, etc. ;-) having 30min breaks between talks
is really good as it allows to have an exchange related to presented
topics without impacting timing of the next talk / session (while we
could probably finish little bit later as well to have yet more
MySQL Customer Advisory Forum (CAF) - yet bigger and very well
organized as usually (while I'm not sure if all customers / users are
aware about this great possibility to discuss directly with MySQL
engineering, express all your wishes & issues, get the info from the
source about what is new, what is coming, what is planned, etc.) --
well, I know that many regretted on the last minute to have missed
subscription, so keep in mind this for the next year ;-))
- MySQL Reception - really good! specially that doors were open to anyone, including persons who are not attending the conference -- a true MySQL Community event!
Few wishes anyway for the next year :
would be great to have MySQL posters around the place where conference
is going ;-)
- would be great to have a kind of "closing conference" keynote(s), etc. to make a summary, to thank all attendees & organizers, to have some fun instead just see doors closing and people leaving..
But well, all-in-all - simply great MySQL Conference, which may become only better over a time! so, book your agenda ahead for the next year -- pretty sure it'll be yet more fun ;-)
As promised, here are my presentation slides from my talks on MySQL Central @OpenWord 2014 :
Feel free to ping me if you have any questions, while I'll also try to
cover some of explained topics within the next blog posts, so stay tuned
Monday, 29 September, 2014
Indeed, MySQL 5.7 rocks ;-)
This is the part1 of the following blog posts about various benchmark results on MySQL 5.7 - and this particular one is dedicated to the Sysbench OLTP_RO Point-Select 8-tables workload.
We've already published the over 500K QPS on SQL Point-Selects before @32cores-HT server, so may reconfirm it again with MySQL 5.7 DMR5 -vs- other engines :
and now on a similar server, but with 40cores-HT we're able to confirm 645 QPS on the same workload!
If you missed the long story about how we arrived on such a performance level and how to reproduce the test - you may find all here. This workload is the most killing from all Read-Only Sysbench OLTP tests.. And it's really for the first time we started to scale here with MySQL! - look here (all results are from the 40cores-HT server) :
MySQL 5.5 :
MySQL 5.6 :
MySQL 5.7 :
Percona 5.6 :
MariaDB 10.1 :
As you can see, only MySQL 5.7 rocks here ;-)
However, if you remember the full story, this workload is extremely depending on every extra bits and even insignificant overhead.. - personally it's very rare that I saw a RDBMS workload to be so close to HPC problematic ;-)) -- to remind you that to reach 500K QPS (and 645K QPS here) was necessary to use UNIX socket instead of IP socket and an older Sysbench version binary (v0.4.8) which has just little bit less instructions than the v0.4.13 I'm currently use and will be able to get only 575K QPS on this server..
will tell you yet more during my talk on Wednesday, 1/Oct.
to be continued..