Plainnotes

Container memory: what you see is not the limit

2025-09-03 · 2 min readDeploy

free -h inside a container shows the host's 64G, so a -m 1g limit looks ineffective. free reads /proc/meminfo, and containers share the host's.

The real limit lives in cgroup:

cat /sys/fs/cgroup/memory.max          # cgroup v2
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.stat | grep -E 'anon|file'

memory.current includes page cache, so a container that only reads files creeps toward the limit without leaking — the kernel reclaims under pressure. Watch anon instead; that is the heap and stack the application actually holds.

Old JVMs are a trap here: they miss the cgroup limit, size the heap from host memory, and get OOM-killed at startup. JDK 10 and later enable UseContainerSupport; older ones need -XX:MaxRAMPercentage explicitly.