Wednesday, April 13, 2005
We Got a HeapDump!
We have had a few heapdumps on our Websphere Application Server 5.1 and I am trying to debug the problem.
The first thing I did was read up on the HeapDump itself on the IBM website. The article looks at Memory Leaks and gives you a few options on how to debug the application in error. I chose to use HeapRoots to analyze the HeapDumps. The article indicated that this was the most popular choice.
I downloaded the HeapRoots JAR file from the HeapRoots website and followed the instructions on how to begin analyzing a HeapDump.
A few notes to myself are needed here (feel free to ignore them):
- Instead of using the java.exe path in the article I used c:\program files\Websphere51\AppServer\java\bin\java.exe
- At the command line the path of your compiler must be entirely within " " quotes.
- I entered 1000 for the max depth.
I checked out a thread on WebServerTalk that discusses HeapDumps in Webphere Application Server. In the thread I read about a setting called "verbosegc" that can be set on the Websphere Application Server so that you can monitor Garbage Collection on the server on a Windows box in the native_stderr.log file.
I started down the path of trying to figure out how to set the "verbosegc" setting on my Webphere Application Server. I found the following article on the Webphere website. I have set the setting on my Webphere Application Server and now I am in hover mode while I monitor the Garbage Collection process in the native_stderr.log file.
For in-server Java code, you can turn on tracing for the Java garbage collector by setting the verboseGC server property to true. The trace output describes how often the garbage collector runs, how long it takes, and what objects are deallocated. For information on the encoding of the output, see the documentation for the JDK version that you are running the server with.I am also going to take a look at HeapAnalyzer that is also mentioned in the WebServerTalk thread.
