-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
speed up merge operation for lots of tablets #4574
Conversation
Made two changes to speed up merge. First adjusted the sleep time for one of the Fate steps to consider how long a scan took. For SplitMillionIT this resulted in ReserveTablets.isReady() sleeping for around 30s instead of 60s. Second when the merge code was deleting tablets it was asking TabletMetadata to save key values and those saved key values were being sorted, even though they did not need to be and were actually already sorted. Changed code to not sort and the resulted in DeleteTablets.call() going from 63s to 55s. Below are the relevant log messages from before and after runs w/ change to not sort. ``` 2024-05-17T18:27:49,635 104 [fate.Fate] DEBUG: Running DeleteTablets.call() FATE:USER:9b3c9abe-a29a-4776-80ee-b0e6c0132d98 took 63328 ms and returned FinishTableRangeOp ``` ``` 2024-05-17T20:20:31,468 103 [fate.Fate] DEBUG: Running DeleteTablets.call() FATE:USER:3f566052-d88d-44dd-9e8b-ac34ed9ca445 took 54710 ms and returned FinishTableRangeO ```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@keith-turner - What do you think about moving part of these changes to main? Specifically, just the Ample changes that change the keyValues from being a SortedMap to a List ? All of that exists in 3.1 so it would things easier going forward if the API was the same in both when merging forward for things like deleteAll()
Looked into the usage in each branch. The following is for main.
and the following if for elasticity ommitting a few false positives related to RootTableMetadata which has function w/. the same name
Seems like the only overlap outside of test is the clone table code, the merge code does not use it in main. The function is used much less in main. Since its used much less in main, would be easy to make the change in main. When merging forward would need to make a lot of the changes in this PR in the merge commit so it would compile. I am fine w/ making the change in main, I am puzzling over what the path of least work is though and if there is some git magic I can leverage. |
If it ends up not being worth making the change in main that is fine too, I just figured I'd bring it up since I noticed it was in main too |
This change was made in elasticity as part of a larger change to speedup merge, see apache#4574. Backported just the part that replaced a sortedmap w/ a list in TabletMetadata to speed up the code that tracks a tablets key/values.
This change was made in elasticity as part of a larger change to speedup merge, see #4574. Backported just the part that replaced a sortedmap w/ a list in TabletMetadata to speed up the code that tracks a tablets key/values.
The fate step that reserves tablets for merge was signaling it was ready when it was not in the case where its scan of the metadata table took 0ms. This was causing some ITs to fail. The bug was introduced in apache#4574
The fate step that reserves tablets for merge was signaling it was ready when it was not in the case where its scan of the metadata table took 0ms. This was causing some ITs to fail. The bug was introduced in #4574
Made two changes to speed up merge. First adjusted the sleep time for one of the Fate steps to consider how long a scan took. For SplitMillionIT this resulted in ReserveTablets.isReady() sleeping for
around 30s instead of 60s. Second when the merge code was deleting
tablets it was asking TabletMetadata to save key values and those saved
key values were being sorted, even though they did not need to be and
were actually already sorted. Changed code to not sort and the resulted
in DeleteTablets.call() going from 63s to 55s. Below are the relevant
log messages from before and after runs w/ change to not sort.