I tested the performance of two variants with regard to garbage (clean blocks in buf_pool.flush_list) encountered while searching for the insert position during mtr_t::commit().
garbage |
20 |
40 |
80 |
160 |
320 |
640 |
skip |
173451.92 |
216405.04 |
242115.24 |
222376.35 |
232804.73 |
225682.87 |
collect |
175827.91 |
217642.73 |
244303.73 |
232586.02 |
218409.98 |
225964.44 |
The glitch in the 30-second average throughput at 160 and 320 concurrent threads is probably due to checkpoint flushing. The 10-second intervals with maximum throughput from the same run are as follows:
garbage |
20 |
40 |
80 |
160 |
320 |
640 |
skip |
175404.17 |
228561.55 |
250756.42 |
255970.53 |
246018.71 |
229484.90 |
collect |
177563.37 |
230077.80 |
252248.08 |
256343.42 |
247137.73 |
228197.05 |
The variant with garbage collection seems to perform slightly better.
My first attempt at fixing this could still be improved upon, by refactoring ReleaseModified and its caller so that buf_pool.flush_list_mutex will be acquired and released exactly once, and the correct insert position will be determined only once in case multiple previously clean pages were modified.