Skip to content

Should we set -Xmx (max java heap size) in a kubernetes container


Why bother settings -Xmx and -Xms in a kubernetes app?

We’ve inherited a kubernetes app that is having out of memory errors. It looks like the initial devs set kubernetes resource limits (.95 CPU core and 4Gb memory) as shown below. However, they also set the max heap size in JAVA_OPTS -Xmx to 800mb.

enter image description here

I’ve found lots of good material on best settings for -Xmx (eg this one), but can’t find a straight answer to the following question: do we really need to set -Xmx (and less importantly, -Xms) in a kubernetes container? We’ve already set hard limits on the container resources, so what is the point to setting these flags? If we removed them altogether, what would the consequence be? Would the app GC more often? Would it scale heap size dynamically or would heap size max be fixed at some default maxium like 256MB? Is there any rule of thumb of setting -Xmx in proportion to kubernets containers?


If you don’t set a maximum heap size the behavior depends on the java version used. Current JREs support determining the container limits and use that to guide their internal heuristics.

when running with an older version the memory to be used for the heap will be determined based on the physical memory visible to the container, which might be excessive.

Note that hitting the memory limit of the container will lead to killing the process and restarting the container.

I suggest you use a sane value, as determined from operational testing, for Xmx and Xms to get a stable memory usage.