Stop your containers from stalling when the kernel cgroup v2 pressure kicks in

Technical Briefing | 8/25/2026

You probably have seen your pods sit in a perpetually high latency state even though your metrics show plenty of idle RAM. It feels like the CPU is stuck, but your container logs are clean and the nodes look healthy at a glance. Most engineers point the finger at slow database queries or network congestion, but often the culprit is the pressure stall information mechanism in the kernel quietly throttling your processes because they are thrashing in and out of the page cache.

The kernel is throttling you for your own good

When your container hits its memory limit, the kernel doesn’t just OOM-kill it immediately. If you are on a modern distribution using cgroup v2, the kernel tracks how long threads are waiting for memory or disk I/O. If these stalls exceed a threshold, the kernel puts the brakes on those cgroup processes to protect system stability. The problem is that standard observability tools often miss this, showing you a happy CPU usage graph while your application performance flatlines.

cat /sys/fs/cgroup/system.slice/your-container.service/io.pressure
cat /sys/fs/cgroup/system.slice/your-container.service/memory.pressure

• some means the process is waiting on a resource, but it is not critical
• full means the process is effectively blocked and cannot make progress
• watch the avg10 column for a quick glimpse into the last ten seconds of misery

If you see non-zero values for full, stop tuning your application logic and start looking at your memory limits. Sometimes the fix isn’t more memory, but adjusting how your app uses the page cache. If your app is doing a massive amount of file-backed I/O, the kernel might be trying to reclaim pages from your active memory working set, causing the very pressure stalls you are seeing. Don’t be afraid to pull these metrics into your dashboard, because seeing a spike in pressure stall before a service outage is a lifesaver in production.