Guidelines for setting up your JVM for a Process Commander application
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.]
Setting the New generation heap size
As a general rule, set -XX:NewSize to be one-fourth the size of the heap size. Increase the value of this option for larger numbers of short-lived objects.
Be sure to increase the New generation as you increase the number of processors. Memory allocation can be parallel, but garbage collection is not parallel.
Setting the maximum New generation heap size
Set the maximum size of the New Generation heap size.
Setting New heap size ratios
The New generation area is divided into three sub-areas: Eden, and two survivor spaces that are equal in size.
Configure the ratio of the Eden/survivor space size. Try setting this value to 8, and then monitor your garbage collection.
Setting initial heap size
As a general rule, set initial heap size (-Xms) equal to the maximum heap size (-Xmx) to minimize garbage collections.
Setting maximum heap size
Set the maximum size of the heap.
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
Initial heap size *
* 1536MB has proved to be optimal for most environments. Larger values may require additional CPU capacity and testing to ensure best performance. A Process Commander system requires, at minimum, an -Xmx value of 768MB.
Maximum heap size
Use the same value as –Xms
Initial size of the Permanent Generation
Maximum size of the Permanent Generation
Although a value of 160MB can be used, this is usually insufficient for most enterprise-scale applications.
Uses parallel New Generation GC
Collects the Tenured Generation and attempts to minimize GC pauses by doing most of GC work concurrently with the application thread.
Using this setting in combination with -XX:+UseParNewGC reduces GC pauses for New and Tenured objects.
XX:SurvivorRatio=8 JVM v1.4.2 only
Determines the size of the Eden and Survivor space. Do not use the default value, which is too small.
Percentage of survivor space used after GC scavenge
Increasing from 50% (the default value) improves space utilization by allowing objects to age more in the young generation before being tenured.
-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
Returns error when used with -Xms or –Xmx
Conflicts with NewSize & MaxNewSize
No improvement achieved with this setting. In some cases, has caused system failure.
Likely to cause Permanent Generation to run out of space when doing rules maintenance or application deployment
Attempts to size the heap based on available physical memory. May grow to a size that disrupts the New to Tenured ratio of 1 to 2.
Is enabled by default when using +UseParNewGC
JVM most effectively calculates this value
Sizing physical memory for the server
The server memory requirement is based on the number of JVMs running on your system.
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:
Prints garbage collection information. Because the level of detail is limited, this setting has low overhead and can be switched on in production environments
Writes verboseGC to the specified file
Adds a timestamp to the printed garbage collection information
Prints detailed garbage collection information including heap occupancy for and after GC. This parameter generates a large amount of data to the log file. Ensure there is adequate file system space when enabling this option
Prints detailed garbage collection information
Prints object aging or tenuring information
Dumps heap to file when java.lang.OutOfMemoryError is thrown
Defines path to directory of filename for heap dump
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
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.
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
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.
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.
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.
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 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.
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
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.
GChisto - A GC analysis tool written by members of the Sun Garbage Collection team.
Thanks for posting this useful information. Could you share it's source? Asa moderator, I'm trying to ensure that the forumposts are used more for questions and discussions. If this information is available elsewhere on PDN, it should be searchable and therefore not replicated here, however I appreciate your desire here is to help others, so I'm wondering did you post it as you have had difficulty finding it elsewhere? If so maybe we can improve visibility of content like this and improve PDN.