-
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
Support task resource tracking in OpenSearch #3982
Support task resource tracking in OpenSearch #3982
Conversation
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3982 +/- ##
============================================
+ Coverage 70.50% 70.71% +0.20%
- Complexity 56848 57041 +193
============================================
Files 4583 4585 +2
Lines 273931 274122 +191
Branches 40158 40178 +20
============================================
+ Hits 193146 193845 +699
+ Misses 64561 64001 -560
- Partials 16224 16276 +52 ☔ View full report in Codecov by Sentry. |
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.
Thanks @ketanv3 for the changes. What is the additional delay the await mechanism might introduce. We might need to run benchmarks for this change
Yes, I'm working towards running performance benchmarks. |
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Reopens changes from opensearch-project#2639 (reverted in opensearch-project#3046) to add a framework for task resource tracking. Currently, SearchTask and SearchShardTask support resource tracking but it can be extended to any other task. Changes since opensearch-project#2639: * Replaced the usage of AutoQueueAdjustingExecutorBuilder with ResizableExecutorBuilder * Resolved merge conflicts * Fixed broken tests Signed-off-by: Ketan Verma <[email protected]>
…re stopped Signed-off-by: Ketan Verma <[email protected]>
Signed-off-by: Ketan Verma <[email protected]>
Signed-off-by: Ketan Verma <[email protected]>
dcdaf6e
to
a09a60a
Compare
Gradle Check (Jenkins) Run Completed with:
|
Comparing the accuracy of both approaches – (1) no waiting for task's threads to complete, and (2) using a callback to keep track of active threads – before marking the task as unregistered. An existing integration test was re-used to perform large number of search requests with predictable CPU/memory usage. Measurements were taken for:
Both tests executed 500 search queries and reported resource usages for ~9020 tasks.
Based on these results, approach (2) has been used for the implementation as it gives better accuracy. |
Gradle Check (Jenkins) Run Completed with:
|
Benchmark results
Baseline commit: 740f75d
|
…ion listener Signed-off-by: Ketan Verma <[email protected]>
4e77476
to
d89de65
Compare
Gradle Check (Jenkins) Run Completed with:
|
public void addResourceTrackingCompletionListener(NotifyOnceListener<Task> listener) { | ||
resourceTrackingCompletionListeners.add(listener); | ||
} |
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.
We shouldn't addResourceTrackingCompletionListener if the count is zero, else its possible to that newly added listener is never called.
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.
Fair point, updated.
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.
Though there is still a rare possibility of race-condition:
- Task resource tracking is completed (num threads = 0), and existing completion listeners are invoked.
- Delayed thread execution starts for the task (num threads = 1)
- New completion listener added at this point may succeed.
- Delayed thread execution stops for the task (num threads = 0)
- New completion listener is invoked.
To solve this, we may have to bring back the isResourceTrackingCompleted
atomic boolean into the Task. It's not a concern at the moment as listeners are added during Task creation, not in the middle of execution.
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.
On a different note, this may not even be a problem because a (delayed) thread is still a part of the task, and the newly added listener would just receive the more recent/accurate usage stats.
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.
Yeah we haven't also strictly synchronised adding listeners and invoking them, so I am fine with this limitation as long as it doesn't overcomplicate the use case
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.
Thanks @ketanv3 for the changes, one minor comment
Signed-off-by: Ketan Verma <[email protected]>
Gradle Check (Jenkins) Run Completed with:
|
The backport to
To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-3982-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 5eac54d4ade73f6d0ed80b0f2408a104a98e3232
# Push it to GitHub
git push --set-upstream origin backport/backport-3982-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x Then, create a pull request where the |
* Support task resource tracking in OpenSearch * Reopens changes from opensearch-project#2639 (reverted in opensearch-project#3046) to add a framework for task resource tracking. Currently, SearchTask and SearchShardTask support resource tracking but it can be extended to any other task. * Fixed a race-condition when Task is unregistered before its threads are stopped * Improved error handling and simplified task resource tracking completion listener * Avoid registering listeners on already completed tasks Signed-off-by: Ketan Verma <[email protected]>
* [Backport 2.x] Support task resource tracking in OpenSearch * Reopens changes from #2639 (reverted in #3046) to add a framework for task resource tracking. Currently, SearchTask and SearchShardTask support resource tracking but it can be extended to any other task. * Fixed a race-condition when Task is unregistered before its threads are stopped * Improved error handling and simplified task resource tracking completion listener * Avoid registering listeners on already completed tasks Signed-off-by: Ketan Verma <[email protected]>
Backporting pull requests opensearch-project#2089 and opensearch-project#3982 Signed-off-by: PritLadani <[email protected]>
Description
Reopens changes from #2639 (reverted in #3046) to add a framework for task resource tracking.
Currently, SearchTask and SearchShardTask support resource tracking but it can be extended to any other task in the future.
Changes since #2639:
Signed-off-by: Ketan Verma [email protected]
Issues Resolved
#1179
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.