© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
Hi,
I'm able to reproduce this issue with both 5.6 and 5.7:
single SATA HDD, 8 core amd cpu.
Settings are default for mysql-test-run except for:
--innodb_
Similar results could be obtained with 8MB buffer pool.
I've used 8 sysbench threads (results with 40 are similar).
Version - Transactions per second
5.5-unmodified: 212
5.6-unmodified: 4
5.6-rollback : 68
5.6-us-sleep : 140
5.7-unmodified: 46
5.7-rollback : 69
5.7-us-sleep : 239
As you can see just a rollback will not fix the issue completely.
Original page cleaner thread operates with millisecond sleep time and can increase/decrease delay between LRU cleanup with 50ms step. For modern disks it's unusual delay (even sata hdd could have 8ms write latency).
Thus it looks reasonable to operate with microsecond sleep time (especially for ssd) and 50-100 microsecond increments/
What kind of load should be affected by this patch?
Data set is bigger than buffer pool, there is no / small amount of free pages all the time.
Load is almost read-only or read-only, because in case of insert-only load free pages could be obtained by flushing dirty ones (same case as in 1433432).
Patches for us page cleaner sleep could be found here:
https:/
https:/
Test conditions and raw results:
https:/