Memory limits
The JVM generally requires specifying a maximum memory size it is allowed to use, using theXmx parameter.
That should be set based on the available memory on the application container, which varies with its size.
To extract the container-scaled value on the command line, use $(jq .info.limits.memory /run/config.json).
You should also set the ExitOnOutOfMemoryError.
When you enable this option, the JVM exits on the first occurrence of an out-of-memory error.
Upsun will restart the application automatically.
These are the recommended parameters for running a Java application. Thus, the command to use to start a Java application is:
Garbage collection
When migrating the application to a cloud environment, it is often essential to analyze the Garbage Collector’s log and behavior. For this, there are two options:- Placing the log into the Upsun
/var/log/app.logfile (which capturesSTDOUT). - Creating a log file specifically for the GC.
STDOUT log, you can add the parameter -XX: + PrintGCDetails, E.g.:
The default strategy on Java 9 and later is G1.
The GC strategy to use can be set in the start line with:
Serial
Parallel Garbage Collector
CMS Garbage Collector
G1
Java 8 Optimization
Ideally, all applications should run the latest LTS release of the JVM at least. That is currently Java 11. Java 11 has a number of performance improvements, particularly on container-based environments such as Upsun. However, in many cases, this isn’t possible. If you are still running on Java 8 there are two additional considerations. The default garbage collector for Java 8 is Parallel GC. In most cases G1 will offer better performance. We recommend enabling it, as above. Furthermore, there is theUseStringDeduplication flag which works to eliminate duplicate Strings within the GC process.
That flag can save between 13% to 30% of memory, depending on application. However, this can impact on the pause time of your app.