Tuning the IBM JVM
Every JVM generally offers a whole set of tuning parameters affecting the performance of appservers and applications. Since JVM tuning is a wide and complex topic, this section will present an introduction into garbage collection analysis and tuning in reference to the IBM JVM and provide a series of links and resources for further study.
IBM Java 2 SDK 1.4.1
WAS V5.1 has been upgraded to support IBM Java 2 SDK version 1.4.1 on all platforms, although it still does not yet exploit many features of version 1.4. However, user applications do have access to all new features. More information about the SDK 1.4.1 enhancements can be found at
http://java.sun.com/products/archive/j2se/1.4.1_07/changes.html
Analyzing verbosegc output
Using verbosegc as the next step after using Tivoli Performance Viewer, is a very good way to see what is going on with garbage collection. Verbosegc mode is enabled by the -verbosegc command-line option, and output is directed to the file native_stderr.log. This information can then be used to tune the heap size or diagnose problems. For excellent resources and illustrated examples of verbosegc analysis, refer to the following resources:
Sensible Sanitation: Understanding the IBM Java Garbage Collection Part 3: verbosegc and command-line parameters Fine-tuning Java garbage collection performance http://www.ibm.com/developerworks/ibm/library/i-gctroub/
Common problems
Following is a short list of common problems and suggested solutions:
The GC frequency is too high until the heap reaches a steady state. Use verbosegc to determine the size of the heap at a steady state and set -Xms to this value.
The heap is fully expanded and the occupancy level is greater than 70%. Increase the -Xmx value so the heap is not more than 70% occupied.
At 70% occupancy the frequency of GCs is too great. Change the setting of -Xminf. The default is 0.3, which will try to maintain 30% free space by expanding the heap. A setting of 0.4 increases this free space target to 40%, reducing the frequency of GCs.
Pause times are too long. Try using -Xgcpolicy:optavgpause (introduced in 1.3.1), which reduces pause times and makes them more consistent as the heap occupancy rises. There is a cost to pay in throughput. This cost varies and will be about 5%.
Additional JVM and garbage collection related resources
Garbage collection in the 1.4.1 JVM available from developerWorks at A brief history of garbage collection, developerWorks Sensible Sanitation: Understanding the IBM Java Garbage Collection, Parts 1 and 2, developerWorks IBM JVM Diagnostics Guides from developerWorks Fine-tuning Java garbage collection performance from developerWorks Mark that trash - Incremental compaction in the IBM JDK Garbage Collector http://www.ibm.com/developerworks/ibm/library/i-incrcomp/
Prev | Home | Next WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.