Search Responses to Many Shards use Excessive Amounts of Memory for OriginalIndices instances #78314
Labels
>bug
:Search/Search
Search-related issues that do not fall into other categories
Team:Search
Meta label for search team
Comments
original-brownbear
added
>bug
:Search/Search
|
Pinging @elastic/es-search (Team:Search) |
97 tasks
jimczi
added a commit
that referenced
this issue
Oct 14, 2021
Today the search action send the full list of original indices on every shard request. This change restricts the list to the concrete index of the shard or the alias that was used to resolve it. Relates #78314
jimczi
added a commit
that referenced
this issue
Oct 14, 2021
Today the search action send the full list of original indices on every shard request. This change restricts the list to the concrete index of the shard or the alias that was used to resolve it. Relates #78314
|
Fixed by #78508 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running a simple/fast search on a large number of indices via an index pattern can result in significant memory usage on the coordinating node for the
org.elasticsearch.action.OriginalIndicesinstances in the search responses.When using a simple pattern of e.g.
auditbeat-${long}and searching over 1k indices, this leads to hundreds of MB (and more during heavy load) of duplicate instances on heap that are referenced as such:I think it should be possible to deduplicate these (or even the full search requests referenced in the responses?).
This somewhat relates to #78164 but doesn't just apply to can_match.
The problem with these instances is that they are not accounted for all that well by the circuit breaker in the response collector and it's trivial to OOM a coordinating node if a search targets a large number of indices at once when the responses come back rapidly.
The text was updated successfully, but these errors were encountered: