MDEV-26356 Adaptive purge scheduling based on redo log fill factor
This should be equivalent to pull request #1889 by Krunal Bauskar. The existing logic in purge_coordinator_state::do_purge() activates a number of the configured innodb_purge_threads based on the history list length. Activating more purge worker tasks should shrink the history list faster. But, more purge workers will also generate more redo log, which may slow down writes by user connections. row_purge_parse_undo_rec(): Revert the work-around that was added in commit 46904424. purge_coordinator_state: Keep track of the redo log fill factor (how big percentage of innodb_log_file_size is being occupied by log records that were generated since the latest checkpoint). If the redo log is getting full, log checkpoints will be triggered more frequently, and user threads may end up waiting in log_free_check(). We try to reduce purge-induced jitter in overall throughput by throttling down the active number of purge tasks as the log checkpoint age is approaching the log size (in other words, the redo log fill factor is approaching 100%).
Showing
Please register or sign in to comment