-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Improve thread pools #18613
Comments
Pinging @elastic/es-core-infra |
This issue has been stalled due to complexities of the general threadpool (and others) that are currently unbounded. The concern is that bounding them may cause contention, and could (in theory?) cause deadlocks. I don't think this will be theoretically resolved. We know that having unbounded queues has problems of its own, as outlined here. I propose that we move forward now by implementing the hard bound on queues suggested here (256 * max threads) in master for 8.0. This gives us sufficient time to test through our own daily performance tests, as well as users to test in the alphas/betas for 8.0. |
@rjernst can you comment on what is still missing and what we would need to do next (if anything?), please? |
Pinging @elastic/es-core-infra (Team:Core/Infra) |
This issue is a meta-issue for collapsing several sub-issues for improving thread pools in core Elasticsearch:
The proposal here is that core Elasticsearch will no longer provide support for custom executors. Of course, a plugin can always create an executor on its own and so core Elasticsearch will provide an extension point for such plugins to provide stats back to core Elasticsearch for reading in node stats API and cat thread pools API.
Relates #17915, relates #18491, relates #14448, relates #15866
The text was updated successfully, but these errors were encountered: