Server Settings

Java HotSpot VM Options

This page provides the information about few VM options that can affect the performance of HotSpot JVM.

JVM Memory settings:-

The main memory segments to be considered in JVM memory are Heap and Non-Heap memory segments.

Heap :  The java heap is where the objects of a java program live. It consists of newly created objects, old objects, dead objects and free memory.  When an object is no longer referenced by any part of java program it will be considered as garbage and ready for collection. The memory occupied by the object will be freed once it is collected by garbage collector. The size of the heap decides how frequently and how long garbage collection occurs.

If the size of heap is large - Full garbage collection is slower but occurs very seldom

If the size of heap is small - Full garbage collection is fast but occurs very frequently

Size of the heap should be set in accordance of application memory needs. The goal of tuning the heap size is reducing the time spent by JVM on garbage collection.

JVM heap options:

-Xms - Initial and minimum heap size

-Xmx - Maximum heap size

Setting the minimum heap size equal to maximum heap size is recommended to minimize garbage collections.

-XX:HeapDumpOnOutOfMemoryError - Generate heap dump when out of memory error is thrown.

-XX:HeapDumpPath - Path to file for generating heap dump.

Heap dump gives the information about the live objects and their references

Tri2 production heap settings:

-Xms6144m 

-Xmx8192m

-XX:HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=${TRINITI_HOME}$/HeapDump

Non-Heap:  Non-Heap is where java stores the loaded classes and its meta data. Till JDK 8 this metadata is stored in permanent generation which is a part of heap only. In JDK8 permanent generation is removed and classes metadata is stored in Meta space which is a part of Java process native memory. Hence from JDK8 onward -XX:MaxPermSize option is not considered by JVM and it will be ignored. Meta space capacity is limited by available native memory and also can be limited by new VM option -XX:MaxMetaspaceSize. As permanent generation is removed, there is no more java.lang.OutofMemoryError:PermGen space problems from JDK8.

Tri2 production meta space settings:

There are no settings done for meta space in production server.

JVM Garbage Collection Settings:-

JVM do automatic memory management for all the run time created objects by java application. Automatic memory management includes 

1. Creation and allocation of memory.

2. Determine when the objects are no more referenced.

3. De-allocation of memory.

De-allocation of memory is done by garbage collectors. There are different garbage collectors available in HotSpot JVM which uses different algorithms and runs on different generations of heap. 

Types of Garbage Collectors

1. Serail, ParNew, Parallel Scavenge runs on Young generation

2. Serial Old(Mark Sweep Compact), Concurrent Mark Sweep(CMS) ,Parallel Old runs on Old generation

3. G1 - Same collector used to collect both young and old generations

Garbage collection JVM options

-verbose:gc - It activates a simple GC logging mode and prints a line for every young generation GC and every full GC.

Eg:- 

[GC 246656K->243120K(376320K), 0,0929090 secs]

[Full GC 243120K->241951K(629760K), 1,5589690 secs]

-XX:PrintGCDetails - It activates the detailed GC logging mode and prints more information about GC

Eg;-

[Full GC

    [PSYoungGen: 10752K->9707K(142848K)]

    [ParOldGen: 232384K->232244K(485888K)] 243136K->241951K(628736K)

    [PSPermGen: 3162K->3161K(21504K)],

    1,5265450 secs

]

[Times: user=10,96 sys=0,06, real=1,53 secs]

-XX:+PrintGCTimeStamps - It adds date and time information to GC log.

Eg:-

2014-01-03T12:08:38.102-0100: [GC 66048K->53077K(251392K), 0,0959470 secs]

2014-01-03T12:08:38.239-0100: [GC 119125K->114661K(317440K), 0,1421720 secs]

2014-01-03T12:08:38.513-0100: [GC 246757K->243133K(375296K), 0,2761000 secs]

-Xloggc - By default GC log is written to stdout. With -Xloggc:<Path to file> writes the GC logs to file. It implicitly sets -verbose:gc and -XX:+PrintGCTimeStamps flags.

By analyzing GC logs one can identify how frequently GC occurs and what is triggering GC, is it due to Heap space/Meta space/Explicit GC calls etc. During garbage collection JVM pauses all application threads and uses all the CPU cycles to perform garbage collection. Due to that CPU consumption will be quite high. 

-XX:-DisableExplicitGC - As a part of auto memory management JVM performs garbage collection whenever it is necessary. It is also possible to trigger garbage collection from java application by calling System.gc() and Runtime.gc()  which will invoke Full GC. However this is not recommended to use since it makes to run Full GC every time this code is executed though free space in heap is available. To disable these explicit GC calls, this JVM option has to be set. It will not allow any explicit GC calls but still JVM performs garbage collection when necessary.

-XX:-UseParallelGC - This is the default GC algorithm in JDK8.

-XX:+UseGCLogFileRotation - To rotate the GC log files instead of writing all the gc logs into same file.

-XX:NumberOfGCLogFiles - Defines the number of GC log files to maintain.

-XX:GCLogFileSize - Size of each GC log file when log file rotation flag is set.

Tri2 Production GC VM options

-verbose:gc 

-XX:PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc

-XX:-UseParallelGC

-XX:-DisableExplicitGC

-XX:+UseGCLogFileRotation

-XX:NumberOfGCLogFiles=5

-XX:GCLogFileSize=2M

Client VM vs Server VM:-

HotSpot JVM has two modes Client mode and Server Mode. When JVM is launched in server mode, it performs aggressive optimization than the client mode. Server mode is better suited for production deployments and gives better performance. In case of small applications where there is minimal scope of optimization client mode is preferred.

Tri2 Production VM mode options

-client

Though client VM mode is set in production instance it will be overridden with server VM because 64 bit version of Oracle JVM only supports server mode.

How to do JVM settings in Glassfish server

Follow the below steps to add/modify JVM settings in glassfish server

1. Login to admin console of galssfish

2. Go to Configurations > server-config > JVM Settings > JVM Options

3. Add/Modify new options and save.

After server restart new JVM settings will be applied.