Improve scheduling of background tasks in ReplicatedMergeTree#50107
Improve scheduling of background tasks in ReplicatedMergeTree#50107
Conversation
|
This is an automated comment for commit 5dd9b10 with description of existing statuses. It's updated for the latest CI running
|
f100609 to
f3b4959
Compare
fc6e62b to
3237296
Compare
|
ClickHouse build check - an issue with CI infrastructure |
b140040 to
5dd9b10
Compare
|
Integration tests (asan) [4/6] - #45404 |
This is part of **"Why my PR is not merged?"** patch set series. Since ClickHouse#50107 there one more tunable that can increase the cleanup period - max_cleanup_delay_period. Plus, increase the delay for the cleanup thread, otherwise it is too fragile. Signed-off-by: Azat Khuzhin <[email protected]>
| new_sleep_ms /= storage_settings_ptr->merge_selecting_sleep_slowdown_factor; | ||
| else if (result == AttemptStatus::CannotSelect) | ||
| new_sleep_ms *= storage_settings_ptr->merge_selecting_sleep_slowdown_factor; | ||
| new_sleep_ms *= std::uniform_real_distribution<Float32>(1.f, 1.1f)(thread_local_rng); |
There was a problem hiding this comment.
This is weird and you forgot to write comments.
There was a problem hiding this comment.
It adds a random value to make sure that 1000 tables will not try to assign merges simultaneously (similar to cleanup_delay_period_random_add)
| } | ||
| prev_cleanup_timestamp_ms.store(now_ms, std::memory_order_relaxed); | ||
|
|
||
| sleep_ms += std::uniform_int_distribution<UInt64>(0, storage_settings->cleanup_delay_period_random_add * 1000)(rng); |
There was a problem hiding this comment.
@tavplubix is it expected that cleanup_delay_period_random_add applied after max_cleanup_delay_period ?
There was a problem hiding this comment.
Yes, it always was like this: fa776b9
But I agree that it may be confusing
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Improved scheduling of merge selecting and cleanup tasks in
ReplicatedMergeTree. The tasks will not be executed too frequently when there's nothing to merge or cleanup. Added settingsmax_merge_selecting_sleep_ms,merge_selecting_sleep_slowdown_factor,max_cleanup_delay_periodandcleanup_thread_preferred_points_per_iteration. It should close #31919Checked locally with the usecase from #31919: