-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Run newShardSnapshotTask
tasks concurrently
#126452
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
Run newShardSnapshotTask
tasks concurrently
#126452
Conversation
In elastic#88707 we changed the behaviour here to run the shard-snapshot initialization tasks all in sequence. Yet these tasks do nontrivial work since they may flush to acquire the relevant index commit, so with this commit we go back to distributing them across the `SNAPSHOT` pool again.
Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination) |
Hi @DaveCTurner, I've created a changelog YAML for you. |
// apply some backpressure by reserving one SNAPSHOT thread for the startup work | ||
startShardSnapshotTaskRunner.runSyncTasksEagerly(threadPool.executor(ThreadPool.Names.SNAPSHOT)); |
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.
Is this part really necessary?
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.
I see this is a pattern used else where too. Adds basically one more level on top of throttled task runner which is one more level on top of threadpool. :) Was there a case where the throttled task runner was causing an issue that we had to add this extra piece to it? I'm wondering then if we're just running too many stuff in the same threadpool which lead to this.
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.
The unbounded queue in the ThrottledTaskRunner
is always a worry, yes.
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.
One generic question for my understanding. Otherwise, LGTM.
💔 Backport failed
You can use sqren/backport to manually backport by running |
In elastic#88707 we changed the behaviour here to run the shard-snapshot initialization tasks all in sequence. Yet these tasks do nontrivial work since they may flush to acquire the relevant index commit, so with this commit we go back to distributing them across the `SNAPSHOT` pool again. Backport of elastic#126452 to `8.x`
Backport is #126478 |
In #88707 we changed the behaviour here to run the shard-snapshot initialization tasks all in sequence. Yet these tasks do nontrivial work since they may flush to acquire the relevant index commit, so with this commit we go back to distributing them across the `SNAPSHOT` pool again. Backport of #126452 to `8.x`
In #88707 we changed the behaviour here to run the shard-snapshot
initialization tasks all in sequence. Yet these tasks do nontrivial work
since they may flush to acquire the relevant index commit, so with this
commit we go back to distributing them across the
SNAPSHOT
pool again.