-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Fix SearchContext CB memory accounting #138002
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
base: main
Are you sure you want to change the base?
Conversation
| } | ||
| if (context.checkRealMemoryCB(locallyAccumulatedBytes[0], "fetch source")) { | ||
| // if we checked the real memory breaker, we restart our local accounting | ||
| locallyAccumulatedBytes[0] = 0; |
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.
Most of the time these batches were too small, so this didn't trigger.
| } | ||
| RankFeatureShardPhase.prepareForFetch(searchContext, request); | ||
| fetchPhase.execute(searchContext, docIds, null); | ||
| fetchPhase.execute(searchContext, docIds, null, i -> {}); |
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.
These did not account for memory before anyway, but now they could.
The hard part is releasing the CB; I don't see close+relase logic around here, and I'm not very familiar with this code. Maybe this could be a follow-up
| docIdsToLoad[i] = topDocs.scoreDocs[i].doc; | ||
| } | ||
| FetchSearchResult fetchResult = runFetchPhase(subSearchContext, docIdsToLoad); | ||
| FetchSearchResult fetchResult = runFetchPhase(subSearchContext, docIdsToLoad, this::addRequestCircuitBreakerBytes); |
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.
Should we batch here and avoid invoking the CB for every document?
Maybe addRequestCircuitBreakerBytes should take care of this?
I suspect that fetching source is way more expensive than invoking the CB, so I'm not sure we want more complication here.
|
Hi @luigidellaquila, I've created a changelog YAML for you. |
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
| public final boolean checkRealMemoryCB(int locallyAccumulatedBytes, String label) { | ||
| if (locallyAccumulatedBytes >= memAccountingBufferSize()) { | ||
| circuitBreaker().addEstimateBytesAndMaybeBreak(0, label); | ||
| circuitBreaker().addEstimateBytesAndMaybeBreak(locallyAccumulatedBytes, label); |
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.
This was the crux
Fixing TopHits memory management
Problems and TODO (spotted so far):
SearchContext.checkRealMemoryCBdoesn't account for CB memory (always zero)FetchPhase.buildSearchHitsbatches are too small, the memory buffer never accumulates enough to be trackedTopHitsAggregatormemory management lifecycleInnerHitsPhasememory management lifecycleSearchService.execute*Phase()memory management lifecycleTopHitsAggregator.subSearchContext.closeFuturegrows too much - this is due to this block, so it's irrelevant in prod.Fixes: #136836