Stop the container runtime from lying about your process limits

Technical Briefing | 8/29/2026

You set your memory limits in the pod spec, you see the OOM killer stay quiet, and you assume everything is fine. But I have seen production services crash under load even when htop on the container looks like it has plenty of headroom. The issue is that runc and the cgroup v1 interface often report the total host memory to your process instead of the actual container quota.

The kernel doesnt know your container exists

Most language runtimes like Java or Go look at /proc/meminfo to decide how much heap or GC buffer they should allocate. That file reflects the host state. If your node has 128GB of RAM, your app thinks it can go wild, ignores your 2GB K8s limit, and gets nuked by the kernel cgroup controller before it can even spin up a proper cleanup routine. It is a classic mismatch between userspace perception and kernel-enforced reality.

docker run --rm -m 512m alpine free -h

• The free command reads /proc/meminfo which ignores cgroup limits entirely.
• Use memory.limit_in_bytes from the cgroup mount to see what is really enforced.
• Modern runtimes often have specific flags like -XX:+UseContainerSupport to force awareness.

Fixing the feedback loop

Don’t trust what your application sees at runtime. If you suspect your app is miscalculating its ceiling, check the cgroup stats directly from the host. If your JVM is still ignoring it, you need to bake those memory flags into your deployment environment variables. Next time a pod crashes with exit code 137, look at the cgroup metrics before you start blindly bumping memory requests.