Tuning SPECjAppServer2002

Components

Tuning the JVM - Monitoring

The JVM has a number of monitoring capabilities built into it that can be used to determine how certain command line parameters should be changed. In most cases, the tuning of a JVM will consist of Garbage Collection (GC) avoidance and minimal GC time when it occurs. GC should be avoided as, in most cases, it suspends all other processing in the JVM until the GC phase completes. GC is necessary to clean up Java objects that were allocated, but are no longer used. Refer to the Sun web site (http://java.sun.com or http://java.sun.com/docs/hotspot/gc1.4.2/index.html or http://java.sun.com/docs/hotspot/gc) for more details on GC.

The easiest built in JVM monitoring tool is shown below:

          -verbose:gc

This option instructs the JVM to output information about each GC that takes place. The option outputs the following information:

[GC 91033K->25576K(401408K), 0.0375197 secs]
[GC 91112K->25880K(401408K), 0.0506340 secs]
[GC 91416K->25957K(401408K), 0.0453454 secs]
…
[GC 92108K->26601K(401408K), 0.0601021 secs]
[GC 92137K->26653K(401408K), 0.0618379 secs]
[GC 92189K->26714K(401408K), 0.0628413 secs]

The first number shows the amount of data that was in the JVM heap (memory used by Java to hold Java objects) before GC. The second number shows the amount of data in the JVM heap after GC.  The third number shows the total JVM heap size and fourth number shows how long the GC took. The &150;verbose:gc output can indicate a number of different JVM conditions. Consider the following output:

[Full GC 33188K->24193K(401408K), 10.5970112 secs]

This shows a Full GC that took over 10 seconds to complete. Full GC cycles should be avoided. Not only do they take longer, they cause some disruption to the JVM heap. Seeing frequent Full GC output probably indicates that the total JVM heap is too small and that the total JVM heap needs to be increased along with the Young Generation size.

Monitoring the &150;verbose:gc output for an amount of time could also reveal some tuning opportunities. Consider the following output:

[GC 91033K->25576K(401408K), 0.0375197 secs]
[GC 91112K->25880K(401408K), 0.0506340 secs]
[GC 91416K->25957K(401408K), 0.0453454 secs]
… Time passes …
[GC 92108K->26601K(401408K), 0.0601021 secs]
[GC 92137K->26653K(401408K), 0.0618379 secs]
[GC 92189K->26714K(401408K), 0.0628413 secs]

This output shows a number of minor GCs occurred. Minor GCs tend to take less time than Full GCs and are less destructive to the JVM heap. Notice that the JVM heap remaining after GC is growing, but it&146;s very slowly. The &150;verbose:gc output shown here was captured with the following JVM heap related command line options:

-XX:NewSize=80m –XX:MaxNewSize=80m -Xms400m -Xmx400m

Another way to reduce GC is by using a Parallel Garbage Collector (PGC). A PGC will reduce GC time to a minimum by using multiple GC threads, on multiple CPUs. PGC was introduced in the Sun 1.4.1 JVM. The feature can be turned on by the following command line options:

-XX:+UseParallelGC -XX:ParallelGCThreads=???

As a initial value, the -XX:ParallelGCThreads command line option should be set to the number of CPUs on the server. Several benchmark runs might be required in order to determine the best value to set, either higher or lower than the total number of CPUs. The PGC option will only benefit servers that have more than one CPU. This option typically benefits the SPECjAppServer2002 Application.