JVM Container Memory Sizing Calculator

A JVM in a container does not use the memory you think it does. Enter your container limit and workload shape to see the heap the JVM will actually choose, what the non-heap regions cost on top, and how close the pod is to an OOMKill — then copy the settings that fix it.

Load a scenario

1 · Container

Memory limit (Mi)

The cgroup limit. This is the number the JVM reads, and the number the kubelet kills you at.

Memory request (Mi)

What the scheduler reserves. For memory, this should normally equal the limit.

Node memory (Mi) — if no limit is set

Only used when the limit below is switched off.

Container has a memory limit

2 · Heap sizing

How is the heap sized?

MaxRAMPercentage (%)

3 · Non-heap footprint

Everything the JVM allocates outside the heap. This is where container memory quietly goes — and the region -Xmx tells you nothing about.

Metaspace + class space (Mi)

Loaded classes. A Spring Boot app typically lands between 100 and 180.

JIT code cache (Mi)

Committed, not reserved. Reserve defaults to 240; steady state is far lower.

GC + JVM native structures (Mi)

GC bookkeeping, symbols, JNI, compiler arenas, malloc arenas.

Peak thread count

Tomcat's default max is 200 — plus GC, JIT, scheduler and client pool threads.

Thread stack size -Xss (KB)

1024 KB is the 64-bit Linux default. Reserved per thread, committed on use.

Direct / NIO buffers (Mi)

Netty, HTTP clients, file and socket channels.

APM / instrumentation agent (Mi)

A Java APM agent adds both native memory and classes. Set 0 if you run none.

Safety margin (% of limit)

Absorbs RSS drift, page cache and allocation spikes between GC cycles.

Garbage collector

4 · Results

Where the container's memory goes

What to change

Recommended settings

This is a planning estimate. Non-heap regions — metaspace, code cache, thread stacks, direct buffers, GC and JIT structures — vary with your code, your GC, and your traffic, so treat the defaults here as starting points and replace them with real numbers from native memory tracking (-XX:NativeMemoryTracking=summary plus jcmd <pid> VM.native_memory summary) and from container RSS under load. The one figure that is not an estimate is the heap: when neither -Xmx nor MaxRAMPercentage is set, the JVM takes 25% of the cgroup limit — no more, however much you gave the container.

Where the container's memory goes

What to change

Recommended settingsCopy

Recommended settings