Kubernetes Resource Limits and JVM Heap Size

By default, the JVM’s maximum heap size is 1/4 of the physical memory available - you can read about this in the Oracle GC tuning guide. This means that if you don’t define -Xmx in your JVM parameters, the container will set 1/4 of the host memory as the maximum heap size.

On a recent enough JVM (8u191+ and 10+), the JVM is container-aware: if you set a Kubernetes resource limit, the JVM uses that limit rather than the host’s memory to size the heap. So your maximum heap size becomes 1/4 of your Kubernetes resource limit.

You should also make sure the resource request is larger than the maximum heap size, otherwise the pod can be scheduled onto a node that can’t actually satisfy the heap.

Here’s the approach I’d recommend for setting the maximum heap size:

• Set -Xmx and -Xms explicitly in the JVM parameters rather than relying on the default. Use the JAVA_OPTS environment variable to pass them in.

• Set the Kubernetes resource request to roughly 25% more than the maximum heap size you set with -Xmx. The resource request is the minimum memory guaranteed to the container, and the JVM needs headroom beyond the heap for metaspace, thread stacks and off-heap buffers.

• Set the Kubernetes resource limit to roughly 25% more than the resource request, to give the pod some burst room before it’s OOM-killed.

Let me know your thoughts in the comments below.

• Kubernetes
• Java