Concurrent loading segment cache#18489
Conversation
kfaraz
left a comment
There was a problem hiding this comment.
@GWphua , thanks for the PR! This can be very useful.
For the most part, this PR is moving code from the original method into a new one.
Do you think it is possible to modify the PR such that the diff is minimal?
Otherwise, we might miss some minor step in the review that can lead to bugs later.
|
Hi @kfaraz, I have tried to changes, but the need to add a ExecutorService and use I have created #18494 to help with reviewing this change, please take a look at that. I hope that after merging #18494, diff changes in this PR will be clearer. Thanks! |
| AtomicInteger ignoredfileCounter = new AtomicInteger(0); | ||
| CountDownLatch latch = new CountDownLatch(segmentsToLoad.length); | ||
| ExecutorService exec = Objects.requireNonNullElseGet(loadOnBootstrapExec, MoreExecutors::newDirectExecutorService); |
There was a problem hiding this comment.
drive by comment since i haven't had a chance to do a full review yet:
given that the actual load of these segments is already happening concurrently on a pool (by the thing that calls getCachedSegments), I'm wondering if instead of putting deserializing these info files on a thread pool to instead combine reading the info file and mounting the segment into a single thread, instead of threads to load all the infos then more threads to do all the mounts.
That said, it is a bit more involved of a refactor, because SegmentCacheBootstrapper is what currently collects all the metadata today since it blends both the stuff on disk and the separate 'bootstrap' segments to then put onto the pool. Need to think a bit more about what that would look like.
There was a problem hiding this comment.
If I'm understanding you correctly, then the flow will be something like:
- Put getBootstrapSegments() into array.
- Retrieve
File[] segmentsToLoadfromgetEffectiveInfoDir() - Parallelization, each thread does the following:
- Load N cached segments
- loadSegmentOnBootstrap for N cached segments
- Announce the N cached segments.
- Some of the threads that finished working can load the bootstrap segments. (This can happen anytime after (1))
This will indeed involve some refactoring... But I guess we can have the above steps? Let me know if i am missing anything.
…ing-segment-cache
|
Hi @kfaraz, hopefully the changes now are more reviewer-friendly. Can take a look again. Thanks! |
|
Thanks @kfaraz for the review! Comments are resolved, feel free to take a look again. :) |
|
Hi @clintropolis are you still looking at this PR? If there are no further comments, I will be merging this PR soon (maybe by next Friday). Thanks! |
|
Thanks all for the reviews! I will merge this in first, if we need to do further refactoring, new PR's can be created. |
Description
Concurrent loading of cached segments during startup
Previously, we are using 1 thread to run
SegmentLocalCacheManager#getCachedSegments. We may take quite a bit of time if the number of segments is large.We can do better by multithreading using
loadOnBootstrapExec, and speed up segment retrieval.Refactoring
retrieveSegmentMetadataFiles.addFilesToCachedSegmentsLog Changes
Release note
Speed up load of cached segments during Historical startup.
Key changed/added classes in this PR
SegmentLocalCacheManagerSegmentCacheManager+ Relevant implementations.This PR has: