Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6, 10.11, 11.4
Description
The code reads like this
bool paused; |
do |
{
|
latch.wr_lock(SRW_LOCK_CALL);
|
paused= m_FTS_paused || (also_sys && m_SYS_paused);
|
latch.wr_unlock();
|
std::this_thread::sleep_for(std::chrono::milliseconds(10));
|
}
|
while (paused); |
it sleeps. without checking paused, even if paused is false.
It looks wrong, although perhaps it was intended for some purpose, e.g throttle purge activity.
Even if it was intended, then it still needs to be taken out of the function loop, and added to where the throttling needs to actually be, with appropritate comment.
Otherwise it adds 10 ms latency to all of its callers, and to the callers of its callers, which happens more than once during the purge
e.g in wait_FTS/clone_oldest_view/trx_purge and in wait_FTS/close_and_reopen/trx_attach_undo_recs/trx_purge code paths
Other thing : taking a write lock latch.wr_lock just to check the variable, and not change anything is this correct? Looks strange at least.
Attachments
Issue Links
- relates to
-
MDEV-34515 Contention between secondary index UPDATE and purge due to large innodb_purge_batch_size
-
- Closed
-
If this is fixed, I'd reevaluate the change in 10.6 for innodb_purge_batch_size=300 to 1000. I recall having trying out, and having better benchmark results with the old default, but only if this sleep is removed. marko, FYI.