-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
[core][gcs] Fix task events profile events per task leak #42248
[core][gcs] Fix task events profile events per task leak #42248
Conversation
As a follow-up, I think we should add explicit memory consumption regression metrics to GCS and other components for our long running tests. #42250 |
if (existing_task.profile_events().events_size() > max_num_profile_events_per_task) { | ||
auto to_drop = | ||
existing_task.profile_events().events_size() - max_num_profile_events_per_task; | ||
existing_task.mutable_profile_events()->mutable_events()->DeleteSubrange(0, to_drop); |
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.
if to_drop is negative, it will be noop?
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.
it will not enter the if clause in this case.
…#42248) --------- Signed-off-by: rickyyx <rickyx@anyscale.com>
…2268) When a long running task keeps submitting tasks (e.g. driver task, actor task), it generates many profile events as part of task submission. While we already cap the number of profile events in a task at the core worker (where task events are produced and reported), we are not doing that on GCS (the sink), so it's possible when new task events merged to existing ones, it goes unbounded. Signed-off-by: rickyyx <rickyx@anyscale.com>
…#42248) --------- Signed-off-by: rickyyx <rickyx@anyscale.com>
Why are these changes needed?
When a long running task keeps submitting tasks (e.g. driver task, actor task), it generates many profile events as part of task submission.
While we already cap the number of profile events in a task at the core worker (where task events are produced and reported), we are not doing that on GCS (the sink), so it's possible when new task events merged to existing ones, it goes unbounded.
Closes #42144
Related issue number
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.