-
Notifications
You must be signed in to change notification settings - Fork 7.6k
[Core] (Resource Isolation 12/n) Switch group killing policy to by time killing policy #62643
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
Changes from 11 commits
a70ff17
b35865a
5c2599f
8245dbb
caf195e
b886146
a7282df
6609b06
7e7031f
c5a67e2
dc8a434
2c14f01
2884c72
e394d33
251a225
83f9f20
4db1afd
2ce6a98
a177a40
4091330
c2655d3
6a99c1c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -94,6 +94,18 @@ RAY_CONFIG(int64_t, min_memory_free_bytes, (int64_t)-1) | |
| /// killing workers via the worker killing policy. | ||
| RAY_CONFIG(uint64_t, kill_memory_buffer_bytes, 3ULL * 1024 * 1024 * 1024) // 3GB | ||
|
|
||
| /// The threshold monitor is poll based and may miss memory bursts occurring between | ||
| /// polls. This buffer is subtracted from memory.max to give the threshold monitor | ||
| /// time to react before memory max is reached under resource isolation. | ||
| RAY_CONFIG(int64_t, | ||
| threshold_monitor_reaction_buffer_bytes, | ||
| 2LL * 1024 * 1024 * 1024) // 2GB | ||
|
|
||
| /// Whether to use the group-by-owner worker killing policy instead of the | ||
| /// default time-based worker killing policy. When true, workers killed by the | ||
| /// by group killing policy (legacy policy). | ||
|
Kunchd marked this conversation as resolved.
Outdated
|
||
| RAY_CONFIG(bool, WORKER_KILLING_POLICY_BY_GROUP, false) | ||
|
Kunchd marked this conversation as resolved.
Outdated
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks like we are changing the default behavior of the killing policy for all the users. Wondering have we communicated the default behavior to the users and should we gradually roll out the change instead of the directly change the config?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Chatted offline. The new policy behaves very similarly to the existing policy (identical in the common case when the driver is the single source that's submitting the tasks). Additionally, it addresses the issue where the existing policy was not killing aggressively enough to relieve us of memory pressure. We expect the new policy to be a general improvement across the board, but we will modify this PR to make it explicit that there's a behavioral change, and include this in the next version release. We will also leave a comment in the oom log so that users will know how to revert if they experience oom. |
||
|
|
||
| /// The reserved memory bytes for system processes | ||
| /// enforced via cgroup memory.min constraint which guarantees | ||
| /// that the system processes' memory will not be reclaimed under any conditions. | ||
|
|
||
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.
When moving the logic from
threshold_memory_monitor_factor.ccto here, theRAY_CHECKof checking whetheruser_memory_max_bytes_strare missing. Wondering is there a particular reason for that?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.
Yep, the check for whether the string is empty is unnecessary as the underlying call to fetch the constraint value already asserts this.