bug: cgroup v2 memory usage ignores sibling cgroups under the limit-owning ancestor (docker-in-docker, devcontainers)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 72/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- docker, go, kubernetes
- Ambito
- devops, operating-systems
Direzione di ricerca
Locate the memory() entry point and trace how it resolves memory.max, memory.current, and memory.stat; the issue's /init.scope and /docker/ example defines the needed nested cgroup fixture. Verify that usage and the effective limit come from the same ancestor, that the single-process case is unchanged, and that the relevant tests cover the 85% alert and reported memory values.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
In cgroup v2, memory() reads usage (memory.current - inactive_file) from the process's own cgroup but walks up to an ancestor to find memory.max. When the agent is not the only thing under that ancestor, usage is understated. The common case is docker-in-docker or devcontainer workspaces, where the agent sits in /init.scope and nested containers sit in /docker/<id>, both children of the container cgroup that holds the limit.
The result is that resources_monitoring memory alerts in Coder never fire before the container is OOM-killed, and coder stat mem reports a fraction of real usage.
Related: #21 / #22 / #28 fixed where the limit and missing usage files are read from. This is the remaining case: the usage file exists in the agent's cgroup, so no fallback happens, but it does not cover the whole domain the limit applies to.
Reproduction
- Kubernetes pod, cgroup v2, one container with a 14 GiB memory limit, running dockerd inside (docker-in-docker). Coder v2.36.4 (clistat v1.2.1).
- Agent PID 1 is in
0::/init.scope; the devcontainer is in/docker/<id>.init.scope/memory.maxismax, the container root holds the limit. - Allocate ~11 GiB inside the nested container and hold it for 4 minutes.
| Reading | Value |
|---|---|
container root: memory.current - inactive_file / memory.max |
89% |
/docker subtree |
83% |
/init.scope |
5% |
coder stat mem run by the agent |
0.824/14 GiB (6%) |
resources_monitoring memory alert (threshold 85%) |
not triggered |
Expected
Usage should be read from the same cgroup that memory.max was found in, so numerator and denominator describe the same domain. That reports 89% here and the 85% alert fires.
Proposed fix
In memory(), after resolving the ancestor that owns the effective memory.max, read memory.current and memory.stat (inactive_file) from that ancestor rather than from the process's own cgroup. When the own cgroup holds the limit (the usual single-process container), behavior is unchanged. Happy to send a PR with a test using a nested cgroup fixture (/init.scope + /docker/<id> under a limited root).
Notes:
- Reading the ancestor's files works from inside the container's cgroup namespace (the container root is
/sys/fs/cgroup), no extra privileges needed. - CPU likely has the same shape (
cpu.statfrom own cgroup vscpu.maxfrom ancestor); not verified here.
- Lingua principale
- Go
- Stelle
- 11
- Fork
- 2
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di coder/clistat
-
bug: CPU usage misses other processes that share the same CPU limit (cgroup v2)Forse già presa @DanielleMaywood l’ha presa 3 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 67/100
-
bug: clistat only checks the nearest limit, but every parent's limit applies (cgroup v2)Forse già presa @david-fraley l’ha presa 1 giorno fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
Bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
-
feat: add directory-level disk usage statsForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Apertaenhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
Tutte le issue di coder/clistat
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
area/frontend/library-panels automated-triage type/bug type/ux
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
deskevidence: --dry-run is ignored with --outcome-record, so the record is committed for realApertabug raised-by:verifier
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
medici-finance/assay#4554 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
microsoft/azure-linux-image-tools#954 ·
I maintainer di solito rispondono entro 1 giorno
-
help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno