Stop cgroup v2 from silently killing your containers with OOM lockup

Technical Briefing | 8/18/2026

You probably think your memory limits are hard boundaries. They aren’t. In the shift to cgroup v2, I have seen nodes slide into a state where memory reclaim triggers an infinite loop of direct reclaim and compaction, effectively freezing the container process while the kernel burns CPU cycles. It looks like a hang, but it is actually a resource management deadlock that simple monitoring often misses.

When direct reclaim stops being helpful

When a process hits a memory limit, the kernel starts scanning pages to reclaim. If the pressure is extreme, it gets stuck in direct reclaim mode. Because cgroup v2 changed the accounting semantics, those background reclaim threads now often contend with the workload itself. If you see high sys CPU wait time inside a container that is not actually processing much traffic, you are hitting this wall. It is not always the application leaking memory; it is the kernel struggling to maintain the boundary you defined.

cat /sys/fs/cgroup/memory.stat | grep -E 'pgscan|pgsteal'

• Check if pgscan matches pgsteal for extended periods to confirm a reclaim loop
• Monitor memory.high vs memory.max to see if the kernel is throttling before it kills
• Adjust swappiness for the specific cgroup if you need to favor reclaim over hard locks

Most monitoring tools only track resident set size, which masks the hidden cost of kernel-level page management. If your production services are twitchy under load, dig into the cgroup memory stats. You might find that the kernel is spending more time fighting with its own internal accounting than your application is spending on request logic. When you find the skew, bump the memory limit or tune the reclaim behavior before the system locks up entirely.