-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Increase index_searcher thread count to 2x processor #12196
Conversation
Apologies for the last minute change but would really like to get this into 2.12 if possible. |
Thanks Jay for making this change. It makes sense to me to start with 2x the processor count given the change in lucene 9.9, as you explained it is between 1.5x and 2.5x thread count. With 2x, it will multiplex 2 threads on each vCPU atleast to provide benefit for cases when there is some disk IO happening on search thread. |
Compatibility status:Checks if related components are compatible with change 4e986b1 Incompatible componentsSkipped componentsCompatible componentsCompatible components: [https://github.com/opensearch-project/custom-codecs.git, https://github.com/opensearch-project/neural-search.git, https://github.com/opensearch-project/flow-framework.git, https://github.com/opensearch-project/observability.git, https://github.com/opensearch-project/cross-cluster-replication.git, https://github.com/opensearch-project/security-analytics.git, https://github.com/opensearch-project/job-scheduler.git, https://github.com/opensearch-project/opensearch-oci-object-storage.git, https://github.com/opensearch-project/geospatial.git, https://github.com/opensearch-project/notifications.git, https://github.com/opensearch-project/k-nn.git, https://github.com/opensearch-project/asynchronous-search.git, https://github.com/opensearch-project/reporting.git, https://github.com/opensearch-project/ml-commons.git, https://github.com/opensearch-project/sql.git, https://github.com/opensearch-project/common-utils.git, https://github.com/opensearch-project/index-management.git, https://github.com/opensearch-project/anomaly-detection.git, https://github.com/opensearch-project/performance-analyzer-rca.git, https://github.com/opensearch-project/security.git, https://github.com/opensearch-project/alerting.git, https://github.com/opensearch-project/performance-analyzer.git] |
❌ Gradle check result for 74a5af0: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
There are also a lot of failing bwc tests. They shouldn't be related to this change, more likely failed due to the Jenkins issues. Not able to open https://build.ci.opensearch.org/job/gradle-check/33396/ link anymore actually |
❌ Gradle check result for 74a5af0: Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
I think the "todo" here needs to be done: f67ed17#diff-afe8d7298c117ffe707f8755d7e981f9f1103dbd0b040b40642efb555428aeec |
❌ Gradle check result for 74a5af0: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
BWC failures are due to this: #12111 (comment) |
Raised a PR here: #12201 |
74a5af0
to
ba3a847
Compare
@kotwanikunal I just pushed a commit doing the same to this PR too. I'm fine with undoing my changes in favor of your PR or vice versa, no strong preference here. |
Thanks @jed326! |
ba3a847
to
57fe433
Compare
Added |
❕ Gradle check result for ba3a847: UNSTABLE
Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure. |
❌ Gradle check result for 57fe433: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
Signed-off-by: Jay Deng <[email protected]>
57fe433
to
4e986b1
Compare
The backport to
To backport manually, run these commands in your terminal: # Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-12196-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 237cee38a03aa5cc45ccea9ff1017a2744bcfbe4
# Push it to GitHub
git push --set-upstream origin backport/backport-12196-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x Then, create a pull request where the |
The backport to
To backport manually, run these commands in your terminal: # Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.12 2.12
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.12
# Create a new branch
git switch --create backport/backport-12196-to-2.12
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 237cee38a03aa5cc45ccea9ff1017a2744bcfbe4
# Push it to GitHub
git push --set-upstream origin backport/backport-12196-to-2.12
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.12 Then, create a pull request where the |
…ect#12196) Signed-off-by: Jay Deng <[email protected]>
Signed-off-by: Jay Deng <[email protected]>
Signed-off-by: Jay Deng <[email protected]>
…ect#12196) Signed-off-by: Jay Deng <[email protected]>
…ect#12196) Signed-off-by: Jay Deng <[email protected]>
…ect#12196) Signed-off-by: Jay Deng <[email protected]> Signed-off-by: Shivansh Arora <[email protected]>
Description
With the Lucene 9.9 changes the
search
threadpool will now offload all the tasks to theindex_searcher
threadpool. Since the number of threads for theindex_searcher
threadpool today isallocatedProcessors
, this will significantly reduce the throughput of concurrent segment search.Previously, there are 1.5x processors for the search threadpool and 1x processors for the index_searcher threadpool, giving 2.5x processor threads available for search. With the Lucene 9.9 change there will only be 1x processors available for the
index_searcher
threadpool to use. Even for the single slice case this is a significant throughput decrease as previously the single slice case would be executed on thesearch
threadpool which has 1.5x processor threads.This PR bumps the
index_searcher
thread count to 2x to move the search throughput back towards the original level.Related Issues
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.