Direct answer

memory.max limits total memory accounted to a cgroup; Java also uses native memory, threads, and other resources outside the heap. Treat a container OOM kill differently from java.lang.OutOfMemoryError.

How to check it

  1. Check the host or panel RAM quota, then read memory.max, memory.current, and memory.events from the server cgroup where accessible.
  2. Compare the oom_kill, oom, and max counters before and after a crash, and examine host/systemd or container exit logs.
  3. Compare configured -Xmx against the quota with headroom for JVM, file caches and native allocations.

What to change

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.events
  1. Do not set -Xmx equal to the advertised container memory limit.
  2. If counters indicate OOM kills, test a smaller heap allocation or ask for a larger container limit.
  3. If the Java log shows heap exhaustion but cgroup has ample headroom, investigate heap use and plugin/mod allocations instead.

Software and version notes

Compatibility and safety

Cgroup v1 and managed panels may show different paths or report host memory instead of container memory. Reading these files is safe; changing live control values without understanding the panel is not.

Verify the result

Retest the same workload and check memory.events for new OOM kills, process stability and heap/GC behavior.

References