Monday, 17 November, 2014

MySQL Performance: 5.7 and RDS Aurora, so what?.. ;-)

It was very fun for me to read last week the announces about RDS Aurora - specially the parts related to its performance gain over MySQL: Aurora is claimed to show x5 times better performance than MySQL! However, without publishing any details about ;-) -- and the only details I was able to find until now and group together are the following:

  • Aurora is a proprietary closed source database engine, "compatible" with MySQL (so, not an improved MySQL fork, as many expected..)
  • Sysbench workloads were used to evaluate Aurora performance
  • the only currently published Sysbench results are the following:
    • 500K SELECT/sec
    • 100K UPDATE/sec
  • again, no details about any of the tests..
  • in some articles instead of UPDATE/sec performance was mentioned INSERT/sec, but keeping in mind that there is simply no pure INSERT test available by default within Sysbench workloads, I may only suppose the mentioned 100K writes/sec are corresponding to the UPDATE/sec performance..

Fine then. But, so what?..

Let's see now where we are with MySQL Performance for today?.. ;-))

Yet more than a year ago we already announced 500K SELECT/sec with MySQL 5.7 on Sysbench (and you may read a full story about, if you got it missed). And this year during MySQL Central @OpenWorld we already presented 645K SELECT/sec with the latest MySQL 5.7! - here are the graphs taken from a live load just this morning :
  • the first graphs is showing the SELECT/sec level
  • the second graph - the corresponding amount of concurrent users (sessions) starting with 8, then 16, 32, 64, 128, 256 users

Sysbench SELECT Performance @MySQL 5.7 :

This is a single MySQL instance running on a single HW server. And as you see, we're reaching 645K SELECT/sec since 128 concurrent users. Is the 645K QPS level is the max limit for this server?.. - of course not, it should be possible to do yet more better here by improving our SQL layer, because on the same HW we're able to reach 1M QPS via InnoDB Memcached plugin (where all the data are going the same way directly from InnoDB, but bypassing all the SQL layers).. Work in progress ;-))

Then, what about UPDATE/sec performance?..

Again, a single HW server, single MySQL 5.7 instance, few simple SSD disks (even not a super fast flash storage as we have from Fusion-io and LSI in our LAB) :
  • the first graphs is showing the UPDATE/sec level
  • the second graph - the corresponding amount of concurrent users (sessions) starting with 8, then 16, 32, 64, 128, 256 users

Sysbench UPDATE Performance @MySQL 5.7 :

As you can see, we're doing even slightly more than 100K UPDATE/sec here ;-)

And you may ask then: Why MySQL Team @Oracle did not publish such a great result on UPDATE performance?.. - Well, just because there is nothing to be proud of for the moment.. ;-)) Of course, if you'll run the same workload on HDD storage you'll get much more worse results (for ex. on this server with HDD I have only 2K UPDATE/sec).. - so, for sure, SSD is much more efficient for random I/O writes. However, we're not doing better when using a much more faster flash storage than SSD, and this is our main headache today for all IO-bound workloads ;-) -- the limit today is still in the MySQL/InnoDB code itself.. - and we know where, and we're working hard to get it fixed.. And once this stuff will be improved, then we'll have something to be proud of, and then you'll hear about us for sure ;-))

Now, looking back to RDS Aurora results on Sysbench.. - so, what?.. MySQL 5.7 is already doing better! ;-)

Well, still looking for claimed x5 times performance difference..

(NOTE: if you have any troubles to reach over 500K SELECT/sec or 100K UPDATE/sec on MySQL 5.7, I have a webinar right this Wednesday to tell you all about MySQL/InnoDB internals and related tuning, don't hesitate to join:

Posted by Dimitri at 16:40 - Comments...
Categories: MySQL

Wednesday, 29 October, 2014

Speaking about MySQL 5.7 Performance @Percona Live London 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! ;-)

UPDATE - my slides are here : 


Posted by Dimitri at 23:40 - Comments...
Categories: MySQL, news, secondary

Wednesday, 08 October, 2014

Indeed, MySQL 5.7 rocks : OLTP_RO/RW 1-table Benchmarks

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:

Observations :
  • 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
More about RW workloads in the next articles (and about "MySQL-5.7-futexV3" too ;-))

to be continued..
Posted by Dimitri at 11:22 - Comments...
Categories: MySQL

Tuesday, 07 October, 2014

MySQL Central @OpenWorld 2014 was simply great!

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

  • 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 talks?)..

  • 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 ;-)

Bye-Bye, SFO...

Posted by Dimitri at 10:52 - Comments...
Categories: MySQL, news, secondary

My Presentation Slides from MySQL Central @OpenWorld 2014

As promised, here are my presentation slides from my talks on MySQL Central @OpenWord 2014 :

  • MySQL 5.7 Benchmarks [PDF]
  • MySQL Performance : Demystified Tuning & Best Practices [PDF]

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


Posted by Dimitri at 10:40 - Comments...
Categories: MySQL, news, secondary