This document provides guidelines for setting up your JVM for a Process Commander application. The recommended settings and their values are intended only as starting points. The optimal JVM configuration for a given application must be determined after you have deployed it and have performed load testing.

Additionally settings to avoid are described since they may cause unwanted JVM behavior or conflict with the advised settings.

[Important: Tune the JVM after you have resolved performance and memory bottlenecks within the application. Premature JVM tuning will likely produce sub-optimal results that do not address all performance issues.]

 

 

The following settings and values apply to one or more JVMs when running in a multi-node environment in an enterprise-scale system employing multiple CPUs.

Recommended settings and starting values

 

 

Young Generation

 

-XX:NewSize and -XX:MaxNewSize settings bound the minimum and maximum sizes of Young Generation, respectively. Their sizes are computed by JVM as a function of -XX:NewRatio. By default, the setting value is 2 (a ratio of 1:2). For example, if you enter -Xms and -Xmx values to the recommended 1536MB, NewRatio sets Young Generation initial and maximum sizes to 512MB. The Tenured Generation comprises the remaining 1024MB.

[Recommendation: Use the default -XX:NewRatio value and not manually enter NewSize and MaxNewSize settings].

If you manually enter initial and maximum heap sizes to values other than 1536MB, be aware that JVM uses NewRatio to calculate the NewSize and MaxNewSize settings.

Settings that are not recommended

 

 

Sizing physical memory for the server

 

The server memory requirement is based on the number of JVMs running on your system.

1. Calculate the following for each JVM:

JVM memory requirement = -Xmx + -XX:MaxPermSize + 200M (for Java runtime processing)

1. Calculate the following for your server:

Server memory requirement = N * JVM memory requirement + 1 GB (for OS runtime processing)

where N equals the number of JVMs

If the server does not have this amount of physical memory, the operating system will perform page swapping and significantly compromise performance.

Diagnostic tool settings

 

After you have made your initial settings, switch on the garbage collection log file (known as the “verboseGC log” or “verboseGC file”), which collects statistics that you can use to tune and improve JVM performance.

 Use the following settings:

 

 

 

 

Ergonomics - Automatic Selections and Behavior Tuning

 

In the J2SE 5.0 release, default values for the garbage collector, heap size, and HotSpot virtual machine (client or server) are automatically chosen based on the platform and operating system on which the application is running. These automatic selections better match the needs of different types of applications, while requiring fewer command line options than in previous releases.

In addition, a new way of dynamically tuning collection has been added for the parallel garbage collectors. With this approach, the user specifies the desired behavior, and the garbage collector dynamically tunes the sizes of the heap regions in an attempt to achieve the requested behavior. The combination of platform-dependent default selections and garbage collection tuning that uses desired behavior is referred to as ergonomics. The goal of ergonomics is to provide good performance from the JVM with a minimum of command line tuning.

Automatic Selection of Collector, Heap Sizes, and Virtual Machine

 

A server-class machine is defined to be one with

• 2 or more physical processors and
• 2 or more gigabytes of physical memory

 

This definition of a server-class machine applies to all platforms, with the exception of 32-bit platforms running a version of the Windows operating system.

On machines that are not server-class machines, the default values for JVM, garbage collector, and heap sizes are

• the client JVM

• the serial garbage collector

• Initial heap size of 4MB

• Maximum heap size of 64MB

 

On a server-class machine, the JVM is always the server JVM unless you explicitly specify the –client command line option to request the client JVM. On a server-class machine running the server JVM, the default garbage collector is the parallel collector. Otherwise, the default is the serial collector.

On a server-class machine running either JVM (client or server) with the parallel garbage collector, the default initial and maximum heap sizes are

• Initial heap size of 1/64th of the physical memory, up to 1GB. (Note that the minimum initial heap size is 32MB, since a server-class machine is defined to have at least 2GB of memory and 1/64th of 2GB is 32MB.)

• Maximum heap size of 1/4th of the physical memory, up to 1GB.

 

Otherwise, the same default sizes as for non-server-class machines are used (4MB initial heap size and 64MB maximum heap size). Default values can always be overridden by command line options.

Behavior-based Parallel Collector Tuning

 

In the J2SE 5.0 release, a new method of tuning has been added for the parallel garbage collectors, based on desired behavior of the application with respect to garbage collection. Command line options are used to specify the desired behavior in terms of goals for maximum pause time and application throughput.

Maximum Pause Time Goal

 

The maximum pause time goal is specified with the command line option

-XX:MaxGCPauseMillis=n

This is interpreted as a hint to the parallel collector that pause times of n milliseconds or less are desired. The parallel collector will adjust the heap size and other garbage collection-related parameters in an attempt to keep garbage collection pauses shorter than n milliseconds. These adjustments may cause the garbage collector to reduce overall throughput of the application, and in some cases the desired pause time goal cannot be met.

The maximum pause time goal is applied to each generation separately. Typically, if the goal is not met, the generation is made smaller in an attempt to meet the goal. No maximum pause time goal is set by default.

Throughput Goal

 

The throughput goal is measured in terms of the time spent doing garbage collection and the time spent outside of garbage collection (referred to as application time). The goal is specified by the command line option

-XX:GCTimeRatio=n

The ratio of garbage collection time to application time is

1 / (1 + n)

For example -XX:GCTimeRatio=19 sets a goal of 5% of the total time for garbage collection. The default goal is 1% (i.e. n= 99). The time spent in garbage collection is the total time for all generations. If the throughput goal is not being met, the sizes of the generations are increased in an effort to increase the time the application can run between collections. A larger generation takes more time to fill up.

Footprint Goal

 

If the throughput and maximum pause time goals have been met, the garbage collector reduces the size of the heap until one of the goals (invariably the throughput goal) cannot be met. The goal that is not being met is then addressed.

Goal Priorities

 

The parallel garbage collectors attempt to meet the maximum pause time goal first. Only after it is met do they address the throughput goal. Similarly, the footprint goal is considered only after the first two goals have been met.

 

Tools to Evaluate Garbage Collection Performance

 

Various diagnostic and monitoring tools can be utilized to evaluate garbage collection performance. This section provides a brief overview of some of them.

One of the easiest ways to get initial information about garbage collections is to specify the command line option –XX:+PrintGCDetails.

 For every collection, this result in the output of information such as the size of live objects before and after garbage collection for the various generations, the total available space for each generation, and the length of time the collection took.

–XX:+PrintGCTimeStamps

This outputs a timestamp at the start of each collection, in addition to the information that is output if the command line option –XX:+PrintGCDetails is used. The timestamps can help you correlate garbage collection logs with other logged events.

jmap

 

jmap is a command line utility included in the Solaris™ Operating Environment and Linux (but not Windows) releases of the Java Development Kit (JDK). It prints memory–related statistics for a running JVM or core file. If it is used without any command line options, then it prints the list of shared objects loaded, similar to what the Solaris pmap utility outputs. For more specific information, the –heap, –histo, or –permstat options can be used.

The –heap option is used to obtain information that includes the name of the garbage collector, algorithm–specific details (such as the number of threads being used for parallel garbage collection), heap configuration information, and a heap usage summary

The –histo option can be used to obtain a class–wise histogram of the heap. For each class, it prints the number of instances in the heap, the total amount of memory consumed by those objects in bytes, and the fully qualified class name. The histogram is useful when trying to understand how the heap is used.

Configuring the size of the permanent generation can be important for applications that dynamically generate and load a large number of classes (Java Server Pages  and web containers, for example). If an application loads “too many” classes, then an OutOfMemoryError is thrown. The –permstat option to the jmap command can be used to get statistics for the objects in the permanent generation.

 

 

 

jstat

 

The jstat utility uses the built–in instrumentation in the HotSpot JVM to provide information on performance and resource consumption of running applications. The tool can be used when diagnosing performance issues, and in particular issues related to heap sizing and garbage collection. Some of its many options can print statistics regarding garbage collection behavior and the capacities and usage of the various generations.

HPROF: Heap Profiler

 

HPROF is a simple profiler agent shipped with JDK 5.0. It is a dynamically–linked library that interfaces to the JVM using the Java Virtual Machine Tools Interface (JVM TI). It writes out profiling information either to a file or to a socket in ASCII or binary format. This information can be further processed by a profiler front–end tool.

HPROF is capable of presenting CPU usage, heap allocation statistics, and monitor contention profiles. In addition, it can output complete heap dumps and report the states of all the monitors and threads in the Java virtual machine. HPROF is useful when analyzing performance, lock contention, memory leaks, and other issues.

HAT: Heap Analysis Tool

 

The Heap Analysis Tool (HAT) helps debug unintentional object retention. This term is used to describe an object that is no longer needed but is kept alive due to references through some path from a live object. HAT provides a convenient means to browse the object topology in a heap snapshot that is generated using HPROF. The tool allows a number of queries, including “show me all reference paths from the rootset to this object.”

Additional tools are

• VisualVM
• Thread Dump Analyzer - a great all-round thread debugging tool, particularly for identifying deadlocks.
• Samurai, an excellent alternative thread analysis tool, good for iterative dumps over a period of time.
• GC Viewer
• GChisto - A GC analysis tool written by members of the Sun Garbage Collection team.