Consider actual RAM load for scheduling actions
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 75
Description
### Description of the feature request:
To my knowledge, Bazel takes the available amount of RAM for granted, based on `--local_ram_resources`.
This is certainly not always accurate. Running actions might actually exceed their estimated RAM resources or the system might be stressed by non-bazel processes.
This [PR](https://github.com/bazelbuild/bazel/commit/43ad74bec433c1923e2ce78605ea04cac0cdb324) already implements a solution to take the actual CPU load into consideration.
This feature request is about implementing something similar for RAM.
### Which category does this issue belong to?
Performance
### What underlying problem are you trying to solve with this feature?
Bazel scheduling works based on declarative, static assumptions about available system resources and how much resources an action consumes.
Taking actual system load into consideration would improve scheduling and reduce OOM issues.
### Which operating system are you running Bazel on?
_No response_
### What is the output of `bazel info release`?
_No response_
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
_No response_
### What's the output of `git remote get-url origin; git rev-parse HEAD` ?
```text
```
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
Related: https://github.com/bazelbuild/bazel/issues/17368#issuecomment-3144760553
Contributor guide
Research direction
Start by reviewing the referenced CPU-load implementation commit and the discussion in issue #17368, then trace how Bazel scheduling uses --local_ram_resources. Done means the scheduler accounts for actual system RAM load in a comparable way and the behavior is covered by appropriate validation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100