Avoid hoarding cluster state references during rollover #124107
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch. We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need. Fixes elastic#123893
nielsbauman
added
>bug
:Data Management/Indices APIs
Collaborator
|
Pinging @elastic/es-data-management (Team:Data Management) |
Collaborator
|
Hi @nielsbauman, I've created a changelog YAML for you. |
dakrone
approved these changes
Mar 5, 2025
Member
dakrone
left a comment
dakrone
left a comment
There was a problem hiding this comment.
LGTM, thanks for fixing this Niels!
DaveCTurner
reviewed
Mar 5, 2025
Contributor
DaveCTurner
left a comment
DaveCTurner
left a comment
There was a problem hiding this comment.
I wonder if we could come up with a variant of Strings.collectionToDelimitedStringWithLimit that builds the string incrementally. There's no need to keep all the result strings here when we're only keeping the first 1000 characters.
Contributor
Author
I'm sure there is something we can come up with. I don't think it'd be necessary for this PR/bug as the cost is pretty limited now. But ideally, it indeed wouldn't hurt to have something like that. |
Collaborator
💔 Backport failed
You can use sqren/backport to manually backport by running |
nielsbauman
added a commit
to nielsbauman/elasticsearch
that referenced
this pull request
Mar 6, 2025
By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch. We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need. Fixes elastic#123893
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 6, 2025
…24257) By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch. We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need. Fixes #123893
Contributor
Author
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
nielsbauman
added a commit
to nielsbauman/elasticsearch
that referenced
this pull request
Mar 6, 2025
By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch. We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need. Fixes elastic#123893 (cherry picked from commit ff6465b) # Conflicts: # server/src/main/java/org/elasticsearch/action/admin/indices/rollover/LazyRolloverAction.java
nielsbauman
added a commit
to nielsbauman/elasticsearch
that referenced
this pull request
Mar 6, 2025
By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch. We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need. Fixes elastic#123893 (cherry picked from commit ff6465b) # Conflicts: # server/src/main/java/org/elasticsearch/action/admin/indices/rollover/LazyRolloverAction.java
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 6, 2025
… (#124265) # Backport This will backport the following commits from `main` to `8.x`: - [Avoid hoarding cluster state references during rollover (#124107)](#124107) <!--- Backport version: 9.6.4 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 6, 2025
…) (#124266) # Backport This will backport the following commits from `main` to `8.18`: - [Avoid hoarding cluster state references during rollover (#124107)](#124107) <!--- Backport version: 9.6.4 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 6, 2025
…) (#124267) # Backport This will backport the following commits from `main` to `8.17`: - [Avoid hoarding cluster state references during rollover (#124107)](#124107) <!--- Backport version: 9.6.4 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)
georgewallace
pushed a commit
to georgewallace/elasticsearch
that referenced
this pull request
Mar 11, 2025
By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch. We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need. Fixes elastic#123893
costin
pushed a commit
to costin/elasticsearch
that referenced
this pull request
Mar 15, 2025
By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch. We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need. Fixes elastic#123893
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
By keeping a list of all the rollover results in a rollover request batch, we were keeping references to all the intermediate cluster states that we built. We've seen this list take up ~1.4GB with 600 rollover requests in one batch.
We only kept the list of results to compute the "reason" for the allocation reroute, so we can easily drop the cluster state reference from the list and only keep what we need.
Fixes #123893