Garbage collection

Configuration of the memory parameters for the JVM is accomplished by adding <jvm-arg> options in resin.conf that are passed to the JVM when the server is started. The default values for both the maximum heap size and the maximum permanent heap area are too low. It is recommended to increase both values.

 in resin.conf:
 
 <!-- verbose garbage collection -->
 <jvm-arg>-verbose:gc</jvm-arg>
 <jvm-arg>-XX:+PrintGCTimeStamps</jvm-arg>
 <jvm-arg>-XX:+PrintGCDetails</jvm-arg>
 
 <!-- memory settings -->
 <jvm-arg>-Xmx256m</jvm-arg>             <!-- sets the maximum size of the heap (recommended) -->
 <jvm-arg>-XX:MaxPermSize=256m</jvm-arg> <!-- sets the maximum size of the permanent heap (recommended) -->

MaxPermSize

The MaxPermSize - the maximum size for permanent objects in the heap - is a separate space from the heap size specified by -Xmx. Several Resin users have found excessive garbage collection times even when there is plenty of heap space available as reported by -J-verbosegc. In many of these cases, increasing the MaxPermSize solves the issue.

Because MaxPermSize is a maximum size, it is safe to increase its value even if you do not know if your application will actuall need that space.

Solving excessive garbage collection times

The first step for troubleshooting garbage collection issues is to enable <jvm-arg>-XX:+PrintGCTimeStamps</jvm-arg> and <jvm-arg>-XX:+PrintGCDetails</jvm-arg> or something similar in a debugging tool to get an idea of what the JVMs garbage collection is doing.

Make sure both -Xmx and -XX:MaxPermSize are large enough. If the debugging output shows a large number of "FullGC" but there appears to be enough heap space, then the MaxPermSize should probably be increased.

If a Full GC is taking an excessively long time, then check to make sure that the JVM heap is not being swapped to disk by the operating system. A Full GC freezes the entire application in the JVM while the Full GC is performed. If some portion of the JVM heap is swapped to disk, the Full GC will cause it to be swapped back in. Well tuned server environments have no portion of the JVM heap swapped to virtual memory on the disk.

Excessive garbage collection time is usually an indication of a MaxPermSize or swapping issue as described above. The argument <jvm-arg>-XX:MaxGCPauseMillis=5000</jvm-arg> can be used to limit the JVM garbage collection time, in this example to 5 seconds. Usually however excessive garbage collection is better addressed by addressing the underlying problem

The JVM is very good at choosing default garbage collection approaches, and adapting itself over time. Tuning beyond the above steps should be taken after having established a good understanding of the JVM on a production server, as seen over a period of time. A good reference for further tuning options is [[1]]