Yield CPU for concurrent flush and concurrent mergeDelta (#5410) #5423
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automated cherry-pick of #5410
What problem does this PR solve?
Issue Number: close #5409
What is changed and how it works?
Add sleep for
flushCache
andmergeDeltaBySegment
:When
flushCache
is retrying, wait backoff will be 5ms ~ 100ms (considering that existing flushCache usually takes short time to finish).When
mergeDeltaBySegment
is retrying, wait backoff will be 50ms ~ 1s (considering that split-prepare could take several seconds to finish).Check List
Tests
To test with the fix, I introduced a
splitEachSegment
debug function locally to manually trigger a split:The test case is to trigger the split for a 1GB segment, and then perform a mergeDelta at the same time.
Before the fix (using release v6.1):
when there are both split (takes 10s) and mergeDelta (takes 20s in total, blocked by split for 10s), there are 211K retries in 10s when the mergeDelta is blocked:
The CPU usage is around 200% during the split+mergeDelta:
After the fix:
there are only 14 retry attempts with exp backoff:
The CPU usage keeps around 100% (first 11s for split, next 10s for mergeDelta):
Note: As there is maximum 1s backoff, the CPU usage dropped for a short while when split was finished and the mergeDelta was not yet started.
Side effects
Documentation
Release note