Why your pod keeps getting OOMKilled when you have plenty of memory left

Technical Briefing | 11/5/2026

You see it in the logs all the time. The pod restarts, the status says OOMKilled, and you look at your monitoring dashboard only to see memory usage flatlining at 40 percent. You immediately assume the monitoring agent is missing spikes, so you add more resolution, but the graph stays clean. The problem isn’t your metrics; it’s the kernel’s view of memory pressure versus what you see in user space.

The kernel doesn’t care about your rss

Most of us look at resident set size, but the kernel’s OOM killer looks at the whole picture, including cache that it can’t easily drop, or kernel stack memory. When you set memory limits in your manifest, you’re interacting with cgroups v1 or v2. If your application creates a ton of short-lived threads or locks a large shared memory segment, the memory controller marks that memory as non-reclaimable. The OOM killer is ruthless because it has a job to do: keep the node stable, even if it has to sacrifice your pod to do it.

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

• Check if you have anonymous memory growing due to memory leaks in your language runtime
• Look at the oom_score_adj file in the proc filesystem to see how the kernel prioritizes your process
• Verify that your container isn’t hitting limits because of filesystem cache overhead

Digging into the real culprit

If you really want to know what’s happening, stop trusting the dashboard and look at the memory.stat file inside the container cgroup on the node itself. It shows exactly how much memory is categorized as anonymous, file-backed, or swap. If you see high usage in the file-backed bucket that refuses to drop, your application might be holding file descriptors open that force the kernel to keep those pages pinned in RAM. Next time this hits, check the memory.stat before you just blindly throw more resources at a problem that won’t go away.