I am setting up a brand new Java service on AWS. What is the difference between Xms and Xmx sizing relative to total system RAM? How much overhead should I leave for the operating system and non-heap memory areas so the process doesn't get terminated?
3 answers
Calculating these values requires analyzing both heap and non-heap requirements. The Xmx value should never equal the total physical RAM of the machine. The JVM requires significant memory outside the heap for thread stacks, metaspace, and native code allocations. As a standard baseline, set your Xmx to roughly 70% of the available system memory. Once you establish the appropriate maximum size via testing, match your Xms value directly to it to stabilize resource allocation from the moment the application initializes.
Should the combined allocation of our containers on a single host machine ever exceed the physical RAM available, relying on swap space to handle the difference?
A good rule of thumb for dedicated servers is allocating around 70 to 80 percent of total physical memory to your Xmx heap, leaving the rest for the host OS.
Great advice, Melissa. However, if they are running inside Docker containers, they should lower that to about 50 to 60 percent, since container runtimes and metaspace overhead require a tighter cushion to avoid OOM killer intervention.
Absolutely not, Cynthia. Operating Java applications inside swap space completely destroys performance. When the JVM garbage collector scans a heap that has been swapped to a physical disk, performance drops exponentially, leading to severe application timeouts and unresponsiveness.