CPU throttling in cgroup v2 causes latency spikes under concurrent load
0 reputation · 02 Feb 2020, 06:52 UTC
Diagnosing latency with cgroup v2 and PSI
On Ubuntu 22.04 LTS and newer, systemd uses cgroup v2 by default. When multiple requests hit a service, the kernel enforces CPU, memory, and I/O quotas defined in the cgroup hierarchy. CPU throttling is recorded in /sys/fs/cgroup//cpu.stat where nr_throttled and throttled_usec increase whenever the cpu.max quota is exceeded.
Kernel Pressure Stall Information (PSI) provides a quantified view of resource contention. The files /proc/pressure/cpu, /proc/pressure/memory, and /proc/pressure/io expose some and full averages that rise during concurrent workloads, indicating that tasks are stalling on CPU, memory reclamation, or I/O queues.
While the presence of throttling and PSI metrics confirms contention, the documentation does not prescribe specific threshold values or optimal cgroup configurations for mixed concurrent workloads. Operators must decide whether to tighten CPUQuota, set MemoryMax, or adjust systemd-oomd policies, yet no consensus exists on what PSI averages are acceptable before performance degrades.
What PSI threshold values should be considered acceptable for latency spikes in a typical web service? How can we balance CPUQuota and MemoryMax settings to mitigate concurrent‑request throttling without over‑constraining the system? Should systemd‑oomd be relied upon as the primary mitigation, or is manual cgroup tuning required?