Out of Memory (heap leak) specific MustGather information
Debugging the Java virtual machine (JVM) that is running out of Java
heap.
If you suspect a memory leak in the Java™ heap, the first step is
to eliminate any misconfiguration or tuning as a potential cause:
- Increase the Maximum Java Heap Value (-Xmx) and test again.
- Follow instructions for Enabling
verbosegc in WebSphere Application Server
- Ensure that the heap generations (NEW and PERM) are sized
appropriately. Default values for MaxPermSize (Permanent Region)
are often insufficient for applications. The Permanent Region holds class
data and other very long lived resources. MaxPermSize (default
64MB) should be set to a quarter of max heap.
For example:
-XX:MaxPermSize=128m |
|
MaxNewSize, the Young generation is intended for
short-lived objects where Java objects are created and age, from where
they are collected without a Full garbage collection (GC) cycle. Young
Generation (default 32MB) of the heap should be set to a quarter of max
heap size. |
|
For example: |
|
-XX:MaxNewSize=128m |
|
For information on setting these properties, please see
the Generic JVM Arguments section of the following document:
|
|
- Run in HotSpot Server mode (-server). Running in HotSpot
client mode halves the size of the Permanent Region and therefore
increases the stress on this part of the heap in the Sun® JVM.
For more details read, Setting
up a HotSpot server or client mode on a Java 2 SDK.
- Disable System GCs. Another way applications can interact with garbage
collection (GC) is by invoking GCs explicitly, such as through the
System.gc call. These calls force major collection, and inhibit
scalability on large systems.
- Switch to the Alternate Threading Library. The Solaris 8 operating
environment supports an alternate version of libthread that binds threads
to LWPs directly; this might help avoid starvation of the finalization
thread. To try this, set the environment variable
LD_LIBRARY_PATH to include /usr/lib/lwp before launching
the JVM.
For more details refer to: Changing
to the alternate, one-to-one threading library on Solaris 8 improves
performance.
- Stop the WebSphere application Server and recycle the logs
- Restart the application server.
- Run the application until java.lang.OutOfMemory exceptions occur.
If making configuration changes does not resolve the problem and a Java
heap leak is still present, Please collect Heapdumps, following
instructions in Getting
Heapdumps on Solaris platform
Note : Heapdumps can be analyzed using the IBM-developed HeapAnalyzer
tool.
- Collect the following information:
For WebSphere V6.0 and V6.:
- All files in the following directory:
install_root/profiles/profile_name/logs/server_name |
|
- A copy of server.xml located in the following
directory:
install_root/profiles/profile_name/config/cells/
cell_name/nodes/node_name/servers/server_name |
|
For WebSphere V5.0 and V5.1:
- Include all of the files from the following directory:
install_root/logs/server_name |
|
- A copy of server.xml located in the following
directory:
install_root/config/cells/cell_name/nodes/
node_name/servers/server_name |
|
Follow instructions for Submitting
Diagnostic Information to IBM Technical Support for Problem
Determination.
For a listing of all technotes, downloads, and educational materials
specific to the Out of Memory component, search the WebSphere
Application Server support site.
|