Java Heap Options of Productions

Make your Heap Explicit

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly

-XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled


-Xms<heap size>[g|m|k] -Xmx<heap size>[g|m|k]

To avoid dynamic heap resizing and lags, which could be caused by this, we explicitely specify minimal and maximal heap size. Thus Java VM will spend time only once to commit on all the heap.

-XX:PermSize=<perm gen size>[g|m|k] -XX:MaxPermSize=<perm gen size>[g|m|k]
Logic for permanent generation is the same as for overall heap — predefine sizing to avoid costs of dynamic changes. Not applicable to Java >= 8.

-XX:MaxMetaspaceSize=<metaspace size>[g|m|k]
By default Metaspace in Java VM 8 is not limited, though for the sake of system stability it makes sense to limit it with some finite value.

-Xmn<young size>[g|m|k]
Explicitely define size of the young generation.

-XX:SurvivorRatio=<ratio>
Ratio which determines size of the survivour space relatively to eden size. Ratio can be calculated using following formula:

survivor ratio=young size/survivor size  −2

Make GC Right

-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled

As response time is critical for server application concurrent collector feets best for Web applications. Unfortunatelly G1 is still not production ready, thus we have to use Concurrent Mark-Sweep collector.

-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=<percent>

By default CMS GC uses set of heuristic rules to trigger garbage collection. This makes GC less predictable and usually tends to delay collection until old generation is almost occupied. Initiating it in advance allows to complete collection before old generation is full and thus avoid Full GC (i.e. stop-the-world pause). -XX:+UseCMSInitiatingOccupancyOnly prevent usage of GC heuristics. -XX:CMSInitiatingOccupancyFraction informs Java VM when CMS should be triggered. Basically, it allows to create a buffer in heap, which can be filled with data, while CMS is working. Thus percent should be back calculated from the speed in which memory is consumed in old generation during production load. Such percent should be chosen carefully, if it will be small — CMS will work to often, if it will be to big — CMS will be triggered too late and concurrent mode failure may occur. Usually -XX:CMSInitiatingOccupancyFraction should be at the level 70, which mean that application should utilize less that 70% of old generation.

-XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark

Instructs garbage collector to collect young generation before doing Full GC or CMS remark phase and as a result improvde their performance due to absence of need to check references between young generation and tenured.

GC Logging

-XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"<path to log>"

These options make Java to log garbage collector activities into specified file. All records will be prepended with human readable date and time. Meanwhile you should avoid using -XX:+PrintGCTimeStamps as it will prepend record with useless timestamp since Java application start.

Generate log can be later analysed with GCViewer.

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M
GC log files rotation makes analysis of garbage collection problems easier, also it guaranties that disk is protected from space overconsumption.



http://blog.sokolenko.me/2014/11/javavm-options-production.html