Skip to content
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 cgroups v1 and v2 for memory limits #1286

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Support cgroups v1 and v2 for memory limits #1286

wants to merge 3 commits into from

Conversation

dzuelke
Copy link
Contributor

@dzuelke dzuelke commented Jun 26, 2024

For v2, it uses memory.high if available (recommended way of setting a functioning soft limit), then first falls back to memory.max (e.g. from docker run -m), then to memory.low (e.g. from docker run --memory-reservation), and finally to memory.min.

Falls back to direct reading of /sys/fs/cgroup/memory/memory.limit_in_bytes for cases where that exists, but no full cgroupfs is mounted (e.g. on Heroku).

Limit enforcement (now to 8 TB) is still in place this way - a Docker v1 value will be read, and run into the limit for unrestricted containers, without hitting the fallback and getting returned.

GUS-W-16052317

lib/environment.sh Outdated Show resolved Hide resolved
@dzuelke dzuelke force-pushed the cgroupsv2 branch 4 times, most recently from 1888864 to 2771b81 Compare July 1, 2024 10:57
Uses memory.high if available (recommended way of setting a functioning soft limit), then first falls back to memory.max (e.g. from 'docker run -m'), then to memory.low (e.g. from 'docker run --memory-reservation'), and finally to memory.min.

Falls back to direct reading of '/sys/fs/cgroup/memory/memory.limit_in_bytes' for cases where that exists, but no full cgroupfs is mounted (e.g. on Heroku).

Limit enforcement (now to 8 TB) is still in place this way - a Docker v1 value will be read, and run into the limit for unrestricted containers, without hitting the fallback and getting returned.

GUS-W-16052317
From https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer:

> Note: The default shell for run steps inside a container is sh instead of bash. This can be overridden with jobs.<job_id>.defaults.run or jobs.<job_id>.steps[*].shell.
fi
}

dne_memory() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does dne stand for?

return
}

if (($? == 99)); then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a brief comment about exit code 99 would be nice

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dzuelke this file contains all the "shared" logic between buildpacks, right? if changes occur will we be manually keeping these in sync? is the PHP version the canonical one since it contains most of the underlying tests?

@dzuelke dzuelke marked this pull request as draft July 19, 2024 14:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants