I think that instead of doing this, we should benchmark and evaluate the current architecture. Could the interplay between the purge coordinator and worker threads be improved? A simpler architecture could as a side effect fix MDEV-11802.
For a benchmark, I would suggest something like the following:
START TRANSACTION WITH CONSISTENT SNAPSHOT; -- stops purge
|
-- run a well defined load of INSERT, UPDATE, DELETE (no ROLLBACK) in other connections
|
COMMIT; -- releases purge
|
-- then, repeat the following until History list length reaches 0, and measure the time
|
SHOW ENGINE INNODB STATUS;
|
During the last phase it would also be beneficial to run perf record or similar, to see where the time is being spent. It would also be useful to monitor the CPU usage with top or similar, to see if purge is actually running as fast as possible on an otherwise idle system, until there is no work to do.
Task
Major
MDEV-11802 innodb.innodb_bug14676111 fails in buildbot due to InnoDB purge failing to start when there is work to do
I think that instead of doing this, we should benchmark and evaluate the current architecture. Could the interplay between the purge coordinator and worker threads be improved? A simpler architecture could as a side effect fix
MDEV-11802.For a benchmark, I would suggest something like the following:
-- run a well defined load of INSERT, UPDATE, DELETE (no ROLLBACK) in other connections-- then, repeat the following until History list length reaches 0, and measure the timeSHOW ENGINE INNODB STATUS;During the last phase it would also be beneficial to run perf record or similar, to see where the time is being spent. It would also be useful to monitor the CPU usage with top or similar, to see if purge is actually running as fast as possible on an otherwise idle system, until there is no work to do.