How to set up Sun JVM v1.4.2 and v1.5
Summary
This article provides guidelines for setting up your JVM when you begin building 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.
Also described are settings to avoid because 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.
Suggested Approach
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
Setting | Starting Value | Description |
|---|---|---|
-Xms | -Xms1536m | Initial heap size * |
-Xmx | -Xmx1536m | Maximum heap size Use the same value as –Xms |
-XX:PermSize | -XX:PermSize=64m | Initial size of the Permanent Generation |
-XX:MaxPermSize | -XX:MaxPermSize=256m | Maximum size of the Permanent Generation |
-XX:+UseParNewGC | N/A | Uses parallel New Generation GC |
| -XX:+UseConcMarkSweepGC | N/A | 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 Do not use the default value, which is too small. |
-XX:TargetSurvivorRatio | -XX:TargetSurvivorRatio=90 | 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. |
* 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.
About setting the size of 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. It is recommended that you 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
Setting | Notes |
|---|---|
-Xmn | Returns error when used with -Xms or -Xmx |
-Xns | Conflicts with NewSize & MaxNewSize |
-server | No improvement achieved with this setting. In some cases, has caused system failure. |
-Xnoclassgc | Likely to cause Permanent Generation to run out of space when doing rules maintenance or application deployment |
-XX:+AggressiveHeap | 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. |
-XX:UseAdaptiveSizePolicy | Is enabled by default when using +UseParNewGC |
-XX:ParallelGCThreads | 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.
- Calculate the following for each JVM:
JVM memory requirement = -Xmx + -XX:MaxPermSize + 200M (for Java runtime processing)
- Calculate the following for your server:
server memory requirement = nJVM 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::
- -verbosegc — Prints garbage collection information. Because the level of detail is limited, this setting has low overhead and can be switched on in production environments.
- -Xloggc:<filename> — Writes verboseGC to the specified file
- -XX:+PrintGCTimeStamps — Adds a timestamp to the printed garbage collection information
You can generate more log file detail by adding the following parameters (which may add overhead):
- -XX:+PrintHeapAtGC — 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.
- -XX:+PrintGCDetails — Prints detailed garbage collection information
- -XX:PrintTenuringDistribution — Prints object aging or tenuring information
To help diagnose memory problems, set the following:
- -XX:+HeapDumpOnOutOfMemoryError — Dumps heap to file when java.lang.OutOfMemoryError is thrown
- -XX:HeapDumpPath=<path to directory> — Defines path to directory of filename for heap dump
Related PDN Articles:
- Support Play: A Tuning the IBM JVM 1.4.2 for performance
Support Play: Tuning the Sun JVM 1.4.2 and 5.0 for performance
Using Performance Tools (PAL), for version 4.2 and for version 5.1, on the System Tools page.
How to detect and remedy the performance impact of Obj-List methods and list view reports
Previous topic How to set up IBM JVM v1.4.2 and v5.0 Next topic How to use SMA to identify amount of data on requestor clipboards