Run newShardSnapshotTask tasks concurrently#126452
Run newShardSnapshotTask tasks concurrently#126452elasticsearchmachine merged 4 commits intoelastic:mainfrom
newShardSnapshotTask tasks concurrently#126452Conversation
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.
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.
The unbounded queue in the ThrottledTaskRunner is always a worry, yes.
pxsalehi
left a comment
There was a problem hiding this comment.
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
SNAPSHOTpool again.