OOMKilled Runbook

Exit code 137 on a Java pod. Work the steps in order — each one rules out a memory region before you touch the heap. Progress is saved in this browser.

1. 1. Confirm it was the kernel, not the JVM

   OOMKilled / exit 137 means the kernel killed the container — there is no Java stack trace. A java.lang.OutOfMemoryError is a different failure with different fixes: triage first.

   Read the guide →
2. 2. Compare the limit against the full footprint

   Import the deployment manifest and run the numbers: if the limit sits close to -Xmx, there was never room for metaspace, stacks, code cache and GC structures.

   Import manifest →Calculator →
3. 3. Check the direct memory budget

   Without -XX:MaxDirectMemorySize, NIO buffers may grow up to another heap-worth of native memory. Netty-heavy services hit this constantly — audit the flags.

   Flags Audit →
4. 4. Count threads

   Each platform thread reserves -Xss (1 MiB by default). A leaking pool turns into native memory growth the heap dashboards never show.

   Thread analyzer →
5. 5. Measure with NMT and cross-check everything

   Enable NMT, run the collect script under real load, and feed all the outputs to the diagnosis session — it shows which region actually grew and consolidates the limit.

   Collect script →Diagnosis session →
6. 6. Close the gap the JVM cannot see

   RSS above NMT committed points at glibc arenas or JNI. Look for the 64 MiB arena signature in smaps; MALLOC_ARENA_MAX=2 is the standard mitigation. Only then resize the heap.

   smaps analyzer →Arenas guide →