Direct answer
-Xmx bounds heap, while Java native allocations and operating-system memory also matter. JVM OutOfMemoryError, container OOM kill and Linux cache usage require different responses.
Recommended procedure
- Read current
-Xmxsettings, usefree -h, and inspect Java RSS withps -p <PID> -o pid,rss,%mem,cmd. - If supported use
jcmd <PID> GC.heap_infofor JVM heap data; avoid assuming it represents all process memory. - On cgroup v2 check
memory.maxandmemory.eventsfor actual quota and OOM events.
What to change
free -h
ps -p <PID> -o pid,rss,%mem,cmd
jcmd <PID> GC.heap_info
cat /sys/fs/cgroup/memory.events- Log readings during idle, warm-up and peak player load before making allocation changes.
- If the container OOM counter increases, leave headroom beyond Xmx or raise the quota with the host.
- For suspected native growth, temporarily enable Native Memory Tracking at startup in a test environment before inspecting
jcmdNMT results.
How to verify the result
Compare heap utilization, RSS, memory.events and stability under the same workload; document whether an error is Java heap or host memory pressure.
Version and safety notes
NMT has overhead and does not track every third-party native allocation. Linux cached memory is not inherently a leak; use MemAvailable and swap/OOM evidence.
Official references
Related guides
Help us improve this article
Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.