Resource Control with cgroups

perf1's own CPU and Memory Bottlenecks chapters covered diagnosing a resource problem system-wide. This chapter closes the loop — once you know which specific service is the actual cause, systemd's own per-service limits are the concrete tool to contain it.

What cgroups Actually Are

Control groups (cgroups) are a Linux kernel feature that groups processes together and lets the kernel enforce resource limits — CPU, memory, I/O — on the group as a whole, not just individual processes. A genuinely important, often-unknown fact: as PID 1 and the ultimate ancestor of essentially every process on the system, systemd automatically places every unit into its own cgroup, by default, whether or not any explicit limit is ever configured. Cgroup accounting already exists per-unit before you ever write a single CPUQuota= line.

Setting Limits — CPUQuota= and MemoryMax=

CPUQuota=50% means this service can use at most 50% of a single CPU core's worth of processing time — even on a multi-core system, even with idle capacity available elsewhere — genuinely enforced by the kernel, not a polite request. MemoryMax= is a hard ceiling; exceeding it triggers the kernel's own OOM killer specifically against this cgroup, rather than the whole system hunting for an arbitrary victim process. MemoryHigh= is the softer companion — a throttling threshold below MemoryMax= that encourages memory reclaim before the hard kill ever becomes necessary.

Why This Matters — the Direct Tie to perf1

perf1's own bottleneck chapters diagnosed resource problems at the whole-system level — a genuinely common real outcome of that kind of investigation is discovering one specific misbehaving service is the actual cause. This chapter's own limits are the concrete containment tool once that diagnosis is made. Concrete scenario: a runaway process — a memory leak in a custom app — that would otherwise eventually exhaust all system memory, potentially taking down unrelated services too. MemoryMax= turns "the whole system's memory" into "just this cgroup's own memory," genuinely containing the blast radius to the one service actually responsible.

systemd-cgtop — Real-Time Per-Unit Resource Usage

A live, top-style view — but organized by cgroup/unit rather than individual process, showing CPU/memory/IO usage per service, in real time. Immediately actionable alongside this chapter's own CPUQuota=/MemoryMax= settings — observe first, then set a limit informed by real usage.

Verifying a Limit Is Actually Enforced

Confirms the configured value actually took effect. systemd1-3's own daemon-reload gotcha applies directly here again — forgetting to reload and restart after adding a resource limit means the old, unrestricted cgroup settings are still what's actually enforced.

Hands-On Exercises