As you may know, flushing in MySQL is an area of my interest, I wrote about it several times, i.e.
In MySQL 5.6 there was implemented a new flushing logic, so I decided to check what do we have now.
For experiment I took tpcc-mysql workload (3 hours runs), 2500W ( ~250GB of data), on Dell PowerEdge 720 box with 150GB buffer pool and with Fusion-io ioDrive 640GB card. InnoDB log file size 2x2000M for MySQL 5.5, and 2x4GB, 2x8GB for MySQL 5.6.
As you can see there is prolonged periods of time (up to few minutes) when throughput drops to 0, and the system is kind of locked up, not being able to process queries.
I should admit there is no more drops to 0, and system is able to maintain 1000 trx / 10 sec in the lowest points, so indeed it is an improvement.
However from a stability standpoint it is far from being perfect.
Another improvement that comes with MySQL 5.6 it is a support of big InnoDB log files, so let’s check if bigger log files helps there and decrease flushing pressure.
You may see that bigger log files, again, improve overall performance, but not stability. With 2x8G logs, there is no sharp peak like with 2000M – 4G logs, but there I guess we have a flushing of dirty pages (I did not gather stats to check it).
As a conclusion: MySQL 5.6 definitely has an improved flushing, but I’d like to see more stable results, so there is a room for improvement.
Relevant MySQL options:
innodb_file_per_table = true
innodb_data_file_path = ibdata1:100M:autoextend
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 256M
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_size = 150G
innodb_log_file_size = 4G
innodb_log_files_in_group = 2
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 20000
innodb_max_io_capacity = 40000