Busy server prefers LRU flushing over flush list flushing too strongly
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.1 |
Invalid
|
Undecided
|
Unassigned | |||
5.5 |
Invalid
|
Undecided
|
Unassigned | |||
5.6 |
Invalid
|
Undecided
|
Unassigned | |||
5.7 |
Fix Released
|
Medium
|
Laurynas Biveinis |
Bug Description
With the current 5.7 version of the fix for https:/
... /* Flush LRU: */
pc_flush(0, 0, &n_processed_lru, &n_flushed_list);
ut_ad(
... /* LRU iteration took too long */
if (ut_time_ms() > next_loop_time)
ret_sleep = OS_SYNC_
... /* Sync flush? */
else if (ret_sleep != OS_SYNC_
&& srv_flush_sync
&& buf_flush_sync_lsn > 0) {
... /* adaptive flush? */
} else if (srv_check_
... /* idle flush? */
} else if (ret_sleep == OS_SYNC_
...
} else {
/* no activity, but woken up by event */
}
Thus, if LRU took too long, we won't go into sync flush, even if that is requested, in which case it will cause performance degradation.
tags: | added: performance xtradb |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/ /jira.percona. com/browse/ PS-3360