Bug #101532 LRU list should still be maintained before the very first eviction
Submitted: 10 Nov 2020 6:10 Modified: 10 Nov 2020 12:38
Reporter: Sok Ann Yap Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S5 (Performance)
Version:8.0 OS:Any
Assigned to: CPU Architecture:Any

[10 Nov 2020 6:10] Sok Ann Yap
Description:
In buf_page_peek_if_too_old(), LRU list is not maintained, i.e. remains FIFO, until after the very first eviction from LRU list flushing:

	if (buf_pool->freed_page_clock == 0) {
		/* If eviction has not started yet, do not update the
		statistics or move blocks in the LRU list.  This is
		either the warm-up phase or an in-memory workload. */
		return(FALSE);
	}

(https://github.com/mysql/mysql-server/blame/ab8ebdf4/storage/innobase/include/buf0buf.ic#L...)

This means the first few iterations of LRU list flushing will likely evict some hot/warm pages, just because they are now at the bottom of the list. This kind of defeating the purpose of the warm-up phase, and also creates unnecessary flushes if these pages happen to be dirty.

While a really hot page at the bottom still won't get evicted (as buf_flush_ready_for_replace() would return false), its existence also makes the LRU list flushing less effective, as each loop to perform buf_LRU_scan_and_free_block() still need to start from the bottom.

How to repeat:
Mostly just follow the code.

It is kinda hard to quantify the benefit/drawback from always maintaining the LRU list, due to the huge performance gap before and after the first LRU list flushing, as the workload transitions from CPU/disk bound to "free list" bound, with the following TODO from WL#5580 remains undone after 9 years:

	TODO: A more elegant way would have been to return the freed
	up block to the caller here but the code that deals with
	removing the block from page_hash and LRU_list is fairly
	involved (particularly in case of compressed pages). We
	can do that in a separate patch sometime in future.

Anyway, by conjecture, the transition would be smoother if the LRU list is always maintained.

Suggested fix:
Either just remove the if-condition, or introduce a flag for users with in-memory workload to retain the current behavior.
[10 Nov 2020 12:38] MySQL Verification Team
Hi Mr. Yap,

Thank you for your performance improvement report.

This performance problem is truly extremely minor. Besides, it is also well analysed and solutions are proposed in the WorkLog entry that you mention.

Also, we do not feel a need to introduce yet another flag, when this operation can be optimised with very few existing parameters.

However, this improvement needs to be scheduled for some version in the future, which is why we will verify this report. Also, performance improvements are introduced only in the latest GA versions or in the development versions only. This is reflected in the target version above.

Verified as reported.