A single runaway service \u2014 a rebuild, a backup, a memory leak \u2014 can starve everything else on a small VPS. cgroups v2 lets you bound each service’s CPU, memory and I\/O so one process cannot take the whole box down. This is a practical setup using systemd units and slices, with verification at every step.<\/p>
stat -fc %T \/sys\/fs\/cgroup\n# cgroup2fs => v2 (unified)\n# tmpfs => v1 (legacy, hybrid)\nsystemctl --version\ncat \/sys\/fs\/cgroup\/cgroup.controllers<\/code><\/pre>If cgroup.controllers<\/code> lists cpu memory io pids<\/code>, the controllers are available. On v1, the syntax below does not apply and you would use the legacy CPUQuota<\/code>\/MemoryMax<\/code> mapping which is less complete.<\/p>The three knobs you actually need<\/h2>Resource<\/th> systemd directive<\/th> cgroup v2 file<\/th><\/tr><\/thead> CPU bandwidth<\/td> CPUQuota=50%<\/td> cpu.max<\/td><\/tr> Memory ceiling<\/td> MemoryMax=512M<\/td> memory.max<\/td><\/tr> Memory throttle (soft)<\/td> MemoryHigh=384M<\/td> memory.high<\/td><\/tr> I\/O bandwidth<\/td> IOReadBandwidthMax=<\/td> io.max<\/td><\/tr> Process count<\/td> TasksMax=256<\/td> pids.max<\/td><\/tr><\/tbody><\/table><\/figure>MemoryHigh<\/code> is the underused one: it throttles and reclaims before MemoryMax<\/code> triggers the OOM killer. Setting only MemoryMax<\/code> lets a service balloon right up to the hard wall and then get killed. Set MemoryHigh<\/code> at ~75% of MemoryMax<\/code> for graceful behaviour.<\/p>Cap a service with a drop-in override<\/h2>
Never edit unit files from the package manager \u2014 use a drop-in so upgrades do not clobber your changes:<\/p>
systemctl edit myservice.service\n\n# --- contents ---\n[Service]\nCPUQuota=75%\nMemoryHigh=384M\nMemoryMax=512M\nIOWeight=50\nTasksMax=512\n<\/code><\/pre>systemctl daemon-reload\nsystemctl restart myservice\nsystemctl show myservice -p CPUQuota -p MemoryMax -p MemoryHigh<\/code><\/pre>Group related services into a slice<\/h2>
Apply one limit to a whole tier \u2014 say all web-adjacent services \u2014 by placing them in a custom slice:<\/p>
# \/etc\/systemd\/system\/webtier.slice\n[Slice]\nCPUQuota=150%\nMemoryMax=1G\n\n# in each unit:\n[Service]\nSlice=webtier.slice<\/code><\/pre>Slices nest, so a parent slice’s limit applies collectively to its children. This is the clean way to give a workload group a budget without hunting down every individual daemon.<\/p>
Verify the limits are real<\/h2># inspect live cgroup values for a running unit\nsystemctl status myservice\ncat \/sys\/fs\/cgroup\/system.slice\/myservice.service\/memory.max\ncat \/sys\/fs\/cgroup\/system.slice\/myservice.service\/cpu.max\n\n# watch memory pressure inside the cgroup\ncat \/sys\/fs\/cgroup\/system.slice\/myservice.service\/memory.events\n# low \/ high \/ max \/ oom_kill counters tell you which wall you hit<\/code><\/pre>The memory.events<\/code> counters are the diagnostic gold: high<\/code> incremented means the soft limit throttled it; max<\/code> means it hit the hard ceiling; oom_kill<\/code> means it died. That single file tells you whether to raise the limit or fix the leak.<\/p>- Start with
MemoryHigh<\/code> slightly below MemoryMax<\/code> so services throttle before they die.<\/li>- Set
CPUQuota<\/code> as a percentage of one core: 200% = two cores.<\/li>- Use
TasksMax<\/code> to stop fork bombs from a compromised or buggy service.<\/li>- Re-verify after every restart; a failed drop-in is silent.<\/li><\/ul>
Testing that the cap actually bites<\/h2>
A limit you have not stress-tested is a limit you do not have. Reproduce load inside the cgroup and watch the accounting counters move:<\/p>
# in one terminal, spin CPU inside the unit's cgroup\nsystemd-run --slice=webtier.slice -p CPUQuota=50% \\\n stress-ng --cpu 4 --timeout 30s\n\n# in another, watch the throttle happen\nsystemctl status <unit>\ncat \/sys\/fs\/cgroup\/webtier.slice\/cpu.stat\n# nr_throttled and throttled_usec rising => the quota is enforced<\/code><\/pre>For memory, allocate past the limit and confirm the throttle-then-kill ladder behaves as configured. If you only see oom_kill<\/code> and never high<\/code> events, your MemoryHigh<\/code> is too close to MemoryMax<\/code> or unset.<\/p>Failure modes and how to spot them<\/h2>Symptom<\/th> Cause<\/th> Fix<\/th><\/tr><\/thead> Service silently unthrottled<\/td> Drop-in not loaded (typo\/daemon-reload missing)<\/td> systemctl show –property to confirm<\/td><\/tr> OOM kills despite a MemoryMax<\/td> cgroup accounting vs host overcommit<\/td> check memory.events + dmesg<\/td><\/tr> I\/O limits ignored<\/td> io controller not delegated or device mismatch<\/td> verify with io.stat and block device<\/td><\/tr> CPUQuota set but no effect<\/td> service forked outside the unit<\/td> use Type=notify \/ KillMode=control-group<\/td><\/tr><\/tbody><\/table><\/figure>The second row is the one people hit on small VPS instances: a cgroup memory limit is not a reservation, and the host’s own overcommit policy still governs total memory. If the box is oversubscribed at the host level, your container or service can still be selected by the host kernel even while respecting its own limit. cgroup limits contain blast radius; they do not conjure memory that the host does not have.<\/p>
Applied consistently, per-service caps convert a class of ‘the whole VPS went down’ incidents into ‘this one service was throttled and logged’. Start with the noisiest, most variable service \u2014 backups, builds, and anything that caches \u2014 and expand from there.<\/p>