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

  1. Read current -Xmx settings, use free -h, and inspect Java RSS with ps -p <PID> -o pid,rss,%mem,cmd.
  2. If supported use jcmd <PID> GC.heap_info for JVM heap data; avoid assuming it represents all process memory.
  3. On cgroup v2 check memory.max and memory.events for 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
  1. Log readings during idle, warm-up and peak player load before making allocation changes.
  2. If the container OOM counter increases, leave headroom beyond Xmx or raise the quota with the host.
  3. For suspected native growth, temporarily enable Native Memory Tracking at startup in a test environment before inspecting jcmd NMT 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

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000