mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-09 20:26:33 +00:00
kevinveenbirkenbachandClaude Opus 5
ffe23287d0
jobs and parallel were derived from the host CPU count with no memory term,
so a 4g container could be asked to run two builds of two sphinx workers
each. One sphinx process reached 2.39 GB anon-rss while still growing, and
the kernel killed two of them ("Memory cgroup out of memory: Killed process
... (sphinx-build)", cgroup usage 4194304kB of limit 4194304kB). Every build
died there, so every page kept answering 202 until the spec gave up.
mem_limit now follows the host, and both knobs follow mem_limit: parallel
takes the builds the limit can hold, then jobs takes the workers left once
every concurrent build has reserved its overhead. Deriving jobs first let it
claim all the memory and pinned parallel at one; reserving the overhead only
once overcommitted an 8-core host by 683 MB.
The two inputs are declared beside the limit they are measured against.
Neither is a ceiling: no docs build has ever completed in CI, so
sphinx_process_mb is a lower bound that the first green build can correct.
mem_limit calls lookup("resource", ...) directly rather than through a
group_var, the way svc-opt-swapfile does: a meta file renders with a flat
variable dict, which cannot expand a group_var that itself holds a lookup
and would have left the limit at 0.
The generator env also lacked the PYTHONUNBUFFERED that _sphinx_env sets,
so a generator killed under that memory pressure lost whatever its stdout
buffer still held. That is why the integrations failure logged its argv and
nothing else.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>