Discussão: Como ler o load average e entender o OOM killer

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Tradução indisponível; é apresentado o original. Original

The advice to protect the primary service with a negative `OOMScoreAdjust` and to bound only the batch jobs assumes the batch job is the one that grows, but on a single-purpose host the process that leaks is usually the primary service itself, and the article's setup then produces the worst outcome. With the service protected, the kernel kills the next-largest candidates one after another (the log shipper, the monitoring agent, eventually `sshd`) while the real consumer keeps growing, and the host ends up unreachable with the leaking service still running. The safer arrangement is the opposite of what the bullet implies: put `MemoryMax=` on the primary service too, sized below physical RAM with room for the system, together with `Restart=on-failure`, so a leak ends in a clean restart of the service inside its own cgroup rather than in the death of the host's other processes. `MemoryHigh=` a little below it gives throttling, and therefore a warning in the metrics, before the kill.