Stop your containers from stalling because of cgroup memory pressure

Technical Briefing | 8/24/2026

You probably think your memory limits are hard boundaries. They aren’t. I’ve spent enough nights watching OOMKill events spike because the kernel was busy thrashing on page caches instead of actually killing the process. Most people assume the kernel handles memory reclamation gracefully, but when you’re running tight limits in a container, the default behavior often leads to a silent, miserable performance degradation before the hammer drops.

The dirty pages lie to you

When your container hits its memory limit, the kernel starts scanning for pages to reclaim. If you have a workload doing heavy I/O, you’re constantly creating dirty pages. The kernel gets stuck trying to flush these to disk faster than your application can generate them. You’ll see high system CPU wait times while the actual user process is starved. This isn’t just about memory; it’s about the kernel trying to keep your container alive when it’s clearly out of headroom.

cat /sys/fs/cgroup/memory/memory.stat | grep -E 'dirty|cache'

• Check the dirty memory stats within the cgroup hierarchy to see how much cache is actually pinned
• Monitor your pressure stall information to distinguish between I/O bottlenecking and actual RAM exhaustion
• Adjust vm.dirty_ratio and vm.dirty_background_ratio on the host if your containers are doing heavy writes

If you are hitting these stalls, stop treating your memory limit as a suggestion. If the application is constantly hovering near the threshold, it is already failing, it just hasn’t crashed yet. Take a look at the memory.stat file while the container is under load; if you see the cache values climbing rapidly, you aren’t fighting a memory leak, you’re fighting a flush-rate bottleneck. Tune your app to use smaller write buffers or move the heavy I/O to a volume that isn’t counting against your container’s cgroup memory limit.

Next time your telemetry shows high latency without an OOMKill, go straight to the cgroup statistics. The kernel is telling you exactly why it’s stalling; you just have to know which files aren’t lying to you.