Performance analysis on V3.5 and V4.0 can use the Java™ 2 SDK profiling function

Technote (FAQ)
Problem
The Performance Analyzer can use the Java™ 2 SDK, V1.2.2 and V1.3.0, profiling function to carry out performance analysis on WebSphere® Application Server V3.5 and V4.0.
Solution
All releases of WebSphere Application Server V3.5 and V4.0 use Java 2 SDK V1.2.2 and V1.3.0. These Java 2 SDKs have the added function over previous SDK versions to perform Java profiling without the need of a separate third party tool. For example: JProbe, OptimizeIt, or Jinsight. Java profiling is ideal for tracking down memory leak problems and other performance problems.

Instructions for using this function is at: http://developer.java.sun.com/developer/onlineTraining/Programming/JDCBook/perf3.html

To use the-Xrunhprof parameters with an Application Server process in WebSphere Application Server, put the parameters in the command line arguments property of Application Server in the administrative console.

To use the -Xrunhprof parameters with the administrative server process, add the parameters to the com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs parameter in the install_root/bin/admin.config file.

To use the -Xrunhprof parameters with the administrative console, add them to the Java™ command line in the install_root/bin/adminclient.sh, or adminclient.bat, file.

Here are suggestions for using this Java heap dump analysis function on all releases of WebSphere Application Server V3.5 with an Application Server memory leak:

  1. Identify that a memory leak is occurring, and that it can be reproduced (either by getting the OutOfMemory exception in the stdout or by seeing free Java Virtual Machine (JVM™) memory going down in "-verbosegc" output in stderr file).

  2. Stop the Application Server, then add the following to its command line arguments property. Depth 20 usually gives a stack track long enough to determine whether an object is being instantiated by WebSphere Application Server or the user application.

    -Xrunhprof:depth=20,file=<filename>

  3. Start the Application Server, then recreate the memory leak. It is not necessary wait for an OutOfMemory exception.

  4. Stop the Application Server, then wait until the Java heap dump file is filled. The heap dump is complete when the line containing SITES END is written to the log.

    If the JVM has problems, the Java heap dump might not output this section, and the heap dump must be performed again.

    Stop the Application Server manually in the administrative console; otherwise, the administrative server restarts the Application Server automatically and overwrites the Java heap dump file.

    Ideally, you can compare results after running the head dump. This excludes objects that might never be dereferenced, but are not taking up additional space during the life of the JVM.

  5. View the Java heap dump file and look at the section titled SITES BEGIN. Identify any object that has a high number of live instantiations. Target these first. Target objects that never dereferenced instantiations during the life of the JVM next. Locate the stack trace for these objects in the Java heap dump file, and analyze them to determine the source of these objects. Most likely, these stack traces help zero in on the source.

  6. Repeating this to get Java heap analysis from two or more different loads also helps eliminate threads of objects that have a high number of instantiations, but does not increase memory usage with differing loads.


You can similarly apply these instructions to all releases of WebSphere Application Server V4.0.











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, Java SDK
Operating system(s): Multi-Platform
Software version: 3.5, 4.0
Software edition: Edition Independent
Reference #: 1006606
IBM Group: Software Group
Modified date: 2004-09-28