You check your pod metrics, see memory usage well below the limit, and assume you have plenty of headroom. Then the OOM killer steps in and wipes out your process anyway. I have spent too many nights debugging this. The problem is that standard tools often report page cache and anonymous memory in a way that hides the actual pressure your application is putting on the kernel.

The kernel is lying to your monitoring stack

The issue stems from how cgroup v2 reconciles working set size against actual page reclamation. When your container is under memory pressure, the kernel starts swapping out inactive pages, but those pages might still show up as part of the cgroup memory usage depending on the specific counter you are querying. You think you are looking at live memory, but you are actually looking at a mix of active heap space and reclaimed pages that are technically still resident in the cgroup’s account.

cat /sys/fs/cgroup/memory.stat | grep -E 'inactive|swap'

• inactive_file tells you how much memory is just sitting there as cache, which the kernel can reclaim instantly
• hierarchical_memory_limit is what you should actually be watching instead of just raw RSS
• memory.events tracks the actual number of times your process hit the limit and triggered an expensive reclaim

If you are seeing memory.events show high numbers for oom_kill or high direct reclaim counts, stop worrying about your heap usage. You are hitting the physical limit of your container configuration, and the kernel is forced to throttle your threads to reclaim space. Next time this hits, check memory.events before you waste hours profiling your memory allocation patterns.