When you have read my previous blog post about MariaDB 10.1 GA performance, you have probably wondered why I didn’t include any numbers for MySQL 5.7. There are two reasons: first MySQL wasn’t GA at that time and secondly MySQL is not running stable on Power8.

Today I will come up with a comparison benchmark. I have chosen some more down-to-earth hardware for that because that is what the majority of our users will be running. Specifically it’s a SP-64 cloud machine from OVH. It has a 4-core Intel CPU and 64G of RAM. Disks aren’t fancy, but the benchmark is again a simplified read-only OLTP workload that runs from memory.

To make things more interesting I added latest MySQL 5.6. So we have now 4 contenders: brand new MySQL 5.7 GA and it’s predecessor and brand new MariaDB 10.1 GA and it’s predecessor. Now after that many words: results!

simplified OLTP, QPS for MySQL and MAriaDBFor those of you that like numbers better than charts:

simplified OLTP – queries per second
clients MariaDB 10.0.21 MariaDB 10.1.8 MySQL 5.6.27 MySQL 5.7.9
1 22166 22748 24456 21499
2 41220 42155 45314 40552
4 70850 72865 78024 69816
8 112328 118933 126892 112442
16 113645 119503 129029 112502
32 113572 119663 127780 112925
64 111003 117255 125526 110663
128 111015 116137 124158 108568
256 111232 115688 116337 102345

So the winner is: MySQL 5.6.27! But there is more to be learned from those numbers. Lets look how the contenders do relatively to each other:

relative results
clients MariaDB 10.1 vs. MariaDB 10.0 MySQL 5.7 vs. MariaDB 10.1 MySQL 5.7 vs. MySQL 5.6
1 +2,6% -5,5% -12,1%
2 +2,3% -3,8% -10,5%
4 +2,8% -4,2% -10,5%
8 +5,9% -5,5% -11,4%
16 +5,2% -5,9% -12,8%
32 +5,4% -5,6% -11,6%
64 +5,6% -5,6% -11,8%
128 +4,6% -6,5% -12,6%
256 +4,0% -11,5% -12,0%

The surprising result of this comparison is that MySQL 5.7.9 is not only slower than MariaDB 10.1.8 (I guess you expected to read that in the MariaDB blog) but it is also significantly slower than MySQL 5.6.27. This unfortunate trend is something that has also been observed by others. MariaDB on the other hand could improve from 10.0.21 to 10.1.8.

Benchmark Details

The benchmark in use was again sysbench. The benchmark is using 1 million rows in a single table. Using single or multiple tables does not make much difference for such a small machine. The my.cnf was as follows:

Notice: the last line is only necessary for MySQL 5.7. And the second last line (disabling performance schema) is only necessary for MySQL. And yes, make sure you disable performance schema or MySQL performance will drop by a few more percent. MariaDB disables performance schema by default.

The sysbench command line was this:

Oracle has now launched MySQL-5.6.10-GA, so it is time to come up with some new benchmark results. The test candidates in this benchmark run are

  • MySQL-5.5.29
  • MySQL-5.6.10
  • MariaDB-5.5.28a
  • MariaDB-10.0.1

The 5.5 versions are in because I wanted to check for any regressions. In the past we have often seen performance regressions in newer versions which were caused by new features.

This time the benchmark was run on a different box. The main difference is that this box does not have SSD but a high performance RAID-5 with 512M of battery-backed cache. Besides that the machine has 16 cores out of which 12 were used for mysqld and the other 4 for sysbench.

The benchmark uses sysbench-0.5 OLTP with 8 tables and 10G worth of data. InnoDB buffer pool was 16G, InnoDB log group capacity 4G (the maximum for MySQL-5.5). The different disk system required different InnoDB configuration:

  • innodb_io_capacity = 1000 (was 20000 for SSD)
  • innodb_flush_neighbors = 1 (was 0 for SSD)

Now for the results. OLTP read only comes first:


And here is the first surprise: MySQL-5.6 behaves significantly different. It competes well up to 8 threads, it even wins 16 threads. But at higher concurrency performance drops off rapidly, even compared to MySQL-5.5. MariaDB-10.0 shows also a slight drop in performance compared to MariaDB-5.5, but it’s much less pronounced.

The response time graph is nice and smooth though:


Both MySQL-5.6 and MariaDB-10.0 look a little better which means they distribute cpu cycles more evenly on concurrent requests.

Disclaimer: no thread pool was used in this benchmark. The Oracle implementation of the thread pool is closed source and thus cannot be benchmarked or used by anybody. It seemed a bit unfair to use the MariaDB thread pool under those cirumstances.

If you want to see the impact of the MariaDB thread pool, have a look at the benchmarks published previously:

Next stop: OLTP read/write:


The picture is very similar. Both MySQL-5.6 and MariaDB-10.0 show a performance drop, compared to the 5.5 versions. For MySQL the drop is more than 10% and thus rather heavy.

However it’s a well known fact that MySQL-5.5 exhibits severe write stalls under high load when InnoDB starts synchronous flushing. The response time graph is good to spot this:


This is the good news. While the 5.5 versions both show heavy write stalls at 64 threads and more, the behavior is much less pronounced with MySQL-5.6 and MariaDB-10.0. So it seems the new adaptive flushing algorithm is working well.

There is however one problem here: if you use multiple buffer pool instances, then you see write stalls more often. For the above results I have run the read-only tests with 16 buffer pools and the read-write tests with only 1.


  • MySQL-5.6 shows a rather severe performance regression, especially at higher concurrency levels. This does not match the results published by Oracle. I can only speculate why the results are so different, but I guess it’s the (closed source) thread pool and maybe the fact that Oracle benchmarks were done on much bigger hardware.
  • with a single buffer pool you don’t have to be afraid of write stalls any more. Also MySQL-5.6 allows now up to 512G redo log capacity which further reduces the odds to run into synchronous flushing (MariaDB-5.5 lifted this limit with XtraDB already)

As always the scripts used for the benchmark as well as the results are available from launchpad:


I invite anybody to rerun this benchmark and share the results.

MariaDB-5.5.21-beta is the first MariaDB release featuring the new thread pool. Oracle offers a commercial thread pool plugin for MySQL Enterprise, but now MariaDB brings a thread pool implementation to the community!

If you are not familiar with the term, please read the Knowledge Base article about it.

The main design goal of the thread pool is to increase the scalability of the MariaDB server with many concurrent connections. In order to test and demonstrate this, I have run the sysbench OLTP RO benchmark with up to 4096 threads to compare the new pool-of-threads and the traditional thread-per-connection scheduler:

OLTP(ro) MariaDB-5.5.21 pool-of-threads vs. thread-per-connection

Benchmark description:

  • sysbench multi table OLTP, readonly
  • 16 tables, totaling 40 mio rows (~10G of data)
  • 16G buffer pool – result is independent of disk performance
  • mysqld bound to 16 cpu cores, sysbench to the other 8

Read/write OLTP benchmark results will be published as soon as they are available.

Raw benchmark results and the scripts used can be downloaded here


Let me add few more words about binding cpu cores and thread pool configuration.

Sysbench-0.5 which was used for this benchmark, turned out to be quite a cpu hog; especially for high concurrency levels. If both mysqld and sysbench are allowed to run on all cpu cores, they will fight for resources – which will result in artificially bad results with many threads. With 4 cores for sysbench and 20 for mysqld, sysbench itself became the bottleneck. So I ended with 8 cores for sysbench (leaving some room here) and 16 for mysqld.

On UNIX, the MariaDB thread pool normally needs no configuration because it autoconfigures thread-pool-size to the number of cpu cores (this depends on sysconf(3) to implement _SC_NPROCESSORS_ONLN) which is in almost all cases the optimal size. If one binds mysqld to a subset of cpu cores, one should set thread-pool-size manually to the number of cpu cores given to mysqld.