When your container is lying about its memory limit

Technical Briefing | 9/5/2026

You set a memory limit of 512MB in your K8s manifest. You see the container humming along at 400MB in your monitoring dashboard, and then—boom—OOMKilled. It’s frustrating because the metrics tool says you’re fine, but the kernel thinks you’re bankrupt. This happens because most monitoring agents look at resident set size, but the kernel’s cgroup memory controller cares about the hard reality of your memory footprint, including things like page cache and kernel buffers that your dashboard might be ignoring.

Why cgroups don’t care about your dashboard metrics

The kernel enforces memory limits through the cgroup memory controller. If your application is actively performing heavy I/O or using specific memory-mapped files, the memory used by those page caches counts toward your limit. Many telemetry collectors exclude page cache from their memory usage numbers to make things look cleaner. But the kernel isn’t looking at your dashboard. When the cgroup hits the memory limit, the OOM killer starts swinging regardless of what your metrics show.

cat /sys/fs/cgroup/memory/memory.stat

• Check memory.stat for cache vs rss fields to see exactly what is consuming your limit
• Watch for the hierarchical memory accounting that includes overhead from your own child cgroups
• Verify if your application is spawning subprocesses that leak memory outside the standard heap

Stop trusting the summary metric in your dashboard when troubleshooting OOM loops. If you see this failing, grab the state from the cgroup files directly on the node. Often you’ll find that your binary isn’t leaking memory so much as the filesystem cache is ballooning under load. If that’s the case, you’ll need to either increase your limit or adjust your application’s I/O patterns. Next time you hit an unexplained OOM, don’t blame the runtime before checking what the kernel actually sees in the cgroup stats.