This is to continue my previous experiments on adaptive flushing in MySQL 5.6.6. Now I am running Ubuntu 12.04, which seems to provide a better throughput than previous system (CentOS 6.3), it also changes the profile of results.
So, as previous I run tpcc-mysql 2500W, against MySQL 5.6.6 with innodb_buffer_pool_size 150GB, and now I vary innodb_buffer_pool_instances as was advised in comments to previous post. I also tried to vary innodb_flushing_avg_loops, but it does not affect results significantly.
So, let’s see throughput with 10 sec averages.
Obviously with innodb_buffer_pool_instances=1 the result is better and more stable.
In fact, if we take 60 sec averages, the picture is following:
On this we could wrap up and be finally satisfied, as we have an almost stable line for Transactions per 60 sec, and we could claim that adaptive flushing algorithm in MySQL 5.6.6 works as expected.
The devil as always is in details. And these details become visible if we go to 1 sec resolution.
This graph is for 1 second averages:
Throughput per 1 sec is scattered through whole range of value, including 0 throughput for 1-4 seconds. So what do we observe there is “micro-stalls”,
which you can’t see if measurement is per 10 sec.
To see it better, let’s zoom-in to 200 sec interval:
In comments to the previous post, I was asked for details.
There is the graph for Checkpoint age
Checkpoint reaches maximal value ( ~75% of 8GB logs) and stays in this level. As I understand checkpoint age balances all time on the limit
and that’s why transactions get stalled.
More metrics and raw results are available from Benchmark Launchpad.
I do not think the current flushing algorithm is good for this workload, and I continue this research as I am interested to find a solution
for cases when we use boxes with a lot memory (100GB+). Percona Server 5.5 also does not handle it quite well, so there is further work to be done.
The post Adaptive flushing in MySQL 5.6 – cont appeared first on MySQL Performance Blog.