Search code examples
javajvmjvm-arguments

What are the downsides of not providing the Xms JVM parameter?

I am looking for a strategy to tweak the JVM parameters for an app I am running.

The app itself is a webapp that most of the time doesn't do much and does not require much memory. Let's say 300MB. Every now and then something external triggers a lot of heavy processing, occasionally requiring more memory. Let's say 1400 MB.

I am running on JDK 15 without any other JVM parameters on a pod in a kubernetes cluster.

I want to:

  • Make sure my app keeps running
  • Make sure my app does not take up much more memory from the underlying system than is actually needed to keep it running.

When looking around for answers, a recommendation that often pops up is to set the Xmx parameter. I understand why and this makes sense to me.

But then there is another common recommendation that puzzles me. It is to set the Xms parameter as well, and set it equal to the Xmx parameter.

The last few weeks I have set both parameters and configured them equally, both to 1400M.

Both parameters set

  • The blue line at the top is how much memory in total is reserved on the underlying system (heap + others)
  • The yellow straight line beneath it is how much memory the JVM actually reserves/commits for the heap.
  • The purple line at the bottom is how much heap memory is actually in use at the moment.

I concluded that everything runs smoothly and looks predictable. What I don't like is that the JVM reserves 1400MB memory at all times (which is exactly what the Xms parameter does I assume), permanently occupying 2.2 GB of the underlying system.

Let's see what happens when I remove the Xms parameter and only set Xmx to 1400:

only Xmx

Here you can see the typical behavior of the app more clearly. How much memory the JVM reserves / commits for the heap is dependent on how much is actually used. It is low most of the time and climbs and falls during the moments of heavy processing.

My question is: Why would I want to set the Xms parameter? The behavior without it looks much more efficient. Are there any downsides I am missing?

Solution

  • If some other application reserves to much memory, your application won't have enough during the next peak.

    The admin can better estimate the memory usage, if the reserved size doesn't change.

    The memory reserved at once will be most probably less fragmented.

    But there is a downside of setting the Xms parameter (besides the obvious one): the garbage collector waits longer until it starts collecting. The garbage collection overhead is more seldom, but heavier. The CPU performance is less stable in this case. In some cases it can cause stop-the-world pauses (for example if you have lot of RAM but weak CPU)