Linux control groups

In cgroup v2, processes belong to a hierarchy and controllers distribute or constrain resources along it. A child cannot escape an ancestor's restriction by declaring a larger local allowance. Consequently, inspecting only a container's leaf settings can miss the actual constraint. Sketch the workload, parent group, host services, and physical machine before diagnosing an apparent mismatch between requested resources and measured throughput.

Use a budget ledger to make the hierarchy concrete. Suppose two services each advertise two CPUs, but their shared parent has only three CPUs of quota. Four CPUs of simultaneous demand cannot fit inside that parent envelope. An operational dashboard should show the parent as well as the children and name the team that owns the shared budget. Otherwise two innocent application teams may repeatedly tune their workers against the same undisclosed ceiling.

CPU weight expresses relative allocation among competing eligible sibling groups; it does not reserve a fixed core count. A CPU quota instead limits aggregate runtime over a period. Several runnable threads can consume that allowance quickly and then wait. If latency rises while CPU usage appears modest over a long averaging window, examine throttling and scheduling intervals rather than immediately assuming the application needs more threads.

Translate an envelope into an application hypothesis using measured CPU demand per successful request. If each request consumes twelve milliseconds of CPU, one sustained CPU-second supports roughly eighty-three such requests. That estimate assumes enough runnable work, unchanged code paths, and no other bottleneck. It does not include queueing delay, network waiting, garbage-collection bursts, or changing instruction efficiency. Test the hypothesis under representative payloads and concurrency before using it for admission policy.

The memory controller's memory.high setting introduces pressure and reclaim when exceeded; memory.max is a hard boundary that can lead to an out-of-memory action when reclaim cannot satisfy an allocation. Memory accounting includes more than the application's preferred heap metric. Compare the group's actual usage and events with the process heap, file-backed cache, and transient allocation patterns. A CPU throttle and a memory kill require different remediation.

For capacity planning, reserve room for measured transient peaks rather than adding a percentage without a reason. Track the largest request, concurrent model loading, and temporary buffers during rollout. Raising every limit simultaneously can merely move failure to the host. A useful experiment changes one envelope, observes successful throughput and tail latency, and records whether another resource became limiting. Kubernetes resource requests and limits are another policy layer; inspect their effective runtime settings instead of assuming that a scheduling request is a benchmark result.