Close popover
Cognizant Technology Solutions

Cognizant Technology Solutions
DilipKMondal Member since 2012 14 posts
Cognizant Technology Solutions
Posted: May 17, 2015
Last activity: May 22, 2015

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


Starting Value




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   -


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.




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





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.

  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:




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.

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


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.


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

  • 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.
Moderation Team has archived post