Generating Heap Dumps and Thread Dumps

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 7
At a glance
Powered by AI
Heap dumps and thread dumps provide snapshot information about the Java heap memory and active threads that can help debug issues like memory leaks and identify hung or blocked threads.

Heap dumps provide information about objects in memory and memory usage while thread dumps provide information about active threads in the system. They are useful for debugging issues like memory leaks, OutOfMemoryExceptions, and identifying hung or blocked threads.

Heap dumps and thread dumps can be generated automatically in WebSphere when OutOfMemoryExceptions occur or manually using wsadmin scripts or OS signals. Heap dumps are stored in the profile directory.

Generating Heap dumps and Thread dumps

Heap Dumps
Heap dump is a text file which keeps record of all objects in the java heap. It contains the
information like size and address of all objects, as well as the addresses of all objects that it
references.

Heap dump is nothing but a snap shot of our JVMs Heap memory,contains all active java
objects and their activities which object doing what and how much memory it is occupying.

whenever OutOfMemoryException occurs Websphere application Server creates heap dump
in profile's home directory.

It is useful in situations, most notable for memory leak problems or memory allocation
problems for exaple OutOfMemoryExceptions.


Automated heap dump generation (Server must start)


Set up for enabling heap dump:

For V6.0 release:
1. To set the following Environment Entries from the administrative console:
Select Servers > Application Servers >server_name> Java and Process
Management > Process Definition > Environment Entries > New
2. Add the following Name/Value pairs:
IBM_HEAPDUMP true
IBM_HEAP_DUMP true
IBM_HEAPDUMPDIR your_directory
IBM_HEAPDUMP_OUTOFMEMORY true
IBM_JAVADUMP_OUTOFMEMORY true
3. Make sure that you save changes to the master configuration


1.Click Servers > Application servers in the administrative console navigation tree.





2.Click server_name >Performance and Diagnostic Advisor Configuration.




3.Click the Runtime tab.



4.Select the Enable automatic heap dump collection check box.




5.Click OK.


Heap Dump:
Heap dump is a text file which keeps record of all objects in the java heap. It contains the information like
size and address of all objects, as well as the addresses of all objects that it references.
Before generating the heap dump, we need to enable the garbage collection to get only live objects
information in dump.
By Default, whenever OutOfMemoryException occurs Websphere application Server create heap dump in
profiles home directory.
Heap dump is nothing but a snap shot of our JVMs Heap memory, so here we can have all active java
objects and their activities which object doing what and how much memory it is occupying.


websphere generate heap dump and java core dump
with jython
WAS_HOME\AppSrv01\bin\wsadmin.sh -lang jython
wsadmin>ServerJVM = AdminControl.completeObjectName(type=JVM,process=server1,*)
wsadmin>AdminControl.invoke(ServerJVM,dumpThreads)
wsadmin>AdminControl.invoke(ServerJVM,generateHeapDump)


Generating Heap dump Manually

set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]

Where server1 is the name of application server for which we want heapdump.

For generating heap dump:

$AdminControl invoke $jvm generateHeapDump


Generating Thread dump Manually

set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]

Where server1 is the name of application server for which we want heapdump.

For generating Thread dump:

$AdminControl invoke $jvm dumpThreads

OR
use kill -3 PID on unix/linux machines.




Thread Dump:
When we trigger a thread dump on an application server, all active thread information will be dumped
into file which is normally known as thread dump. In this dump file, we can get information about thread
like active thread, hung thread, dead lock, runnable and inactive thread info.
Command to generate thread dump: kill -3 PID_OF_SERVER
When our application server reports the thread hung conditions in SystemOut.log file then we generate
thread dump to analyze the reason behinds thread hungs. We are generally having thread hung situation
when any threads coming to system becomes unresponded.
When Websphere Application Server detects that a thread has been active longer than the time defined by
the thread monitor threshold then it write below error code in SystemOut.log file:
WSVR0605W: Thread threadname has been active for hangtime and may be hung. There are
totalthreads threads in total in the server that may be hung.
Where: threadname is the name that appears in a JVM thread dump, hangtime gives an approximation of
how long the thread has been active and totalthreads gives an overall assessment of the system threads.
If the above thread gets released by itself then we get below entry in our log file:
WSVR0606W: Thread threadname was previously reported to be hung but has completed. It was
active for approximately hangtime. There are totalthreads threads in total in the server that still may be
hung.


Automatically


There are some conditions where a thread dump is created automatically for your Java
Virtual Machine (JVM), such as when WebSphere Application Server is stopped by some
means other than a normal stop server request


Thread dumps can also be triggered by issuing a signal to the WebSphere Application
Server process. For example, to produce a thread dump in a UNIX environment, you can
run this command:

kill -3 process_id


In order to manually generate a heapdump, you must first enable signal-based
heapdumps by setting the IBM_HEAPDUMP=TRUE and IBM_NOSIGHANDLER=TRUE
environmental variables.

What is the effect of changing max heap and min heap size of a jvm
Max Heap Size: When you have established the maximum heap size that
you need, you might want to set the minimum heap size to the same value; Using the
same values is not usually a good idea, because it delays the start of garbage collection
until the heap is full. The first time that the Garbage Collector runs, therefore, becomes a
very expensive operation. Also, the heap is more likely to be fragmented and require a heap
compaction. Again this is a very expensive operation.
Min Heap Size: The recommendation is to start your application with
the minimum heap size that it needs. When it starts up, the Garbage Collector will run
often and, because the heap is small, it runs efficiently.

Whats the max heap allowed by AIX
Minimum heap size allowed
AIX: 16 MB
LINUX: 16MB
WINDOWS: 16 MB

Maximum heap size allowed
AIX: Half the available memory with a minimum of 16 MB and a maximum of 512 MB
LINUX: Half the available memory with a minimum of 16 MB and a maximum of
512 MB
WINDOWS: Half the real (physical or RAM) memory with a minimum of 16 MB and a
maximum of 2 GB

What are the effects of large initial heap/max heap
The time between garbage collections will increase, but the garbage collection
will take longer, which indirectly effects the turn-around-time of the applicaiton performance.
(or)
Because it delays the start of garbage collection until the heap is full. The
first time that the Garbage Collector runs, therefore, becomes a very expensive operation.
Also, the heap is more likely to be fragmented and require a heap compaction. Again this is
a very expensive operation.





ANALYZING WEBSPHERE THREAD DUMP
We can take thread dump on WAS using wsadmin tool in the following way.
D:\IBM\WebSphere\AppServer\profiles\ProcessCommander\bin>wsadmin.bat
WASX7209I: Connected to process server1 on node WKHANFXPNode02 using SOAP conn
ector; The type of process is: UnManagedProcess
WASX7029I: For help, enter: $Help help
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
WebSphere:name=JVM,process=server1,platform=proxy,node=WKHANFXPNode02,j2eeType=J
VM,J2EEServer=server1,version=6.1.0.0,type=JVM,mbeanIdentifier=JVM,cell=WKHANFXP
Node01Cell,spec=1.0
wsadmin>$AdminControl invoke $jvm dumpThreads
This will create a java core file in the following directory
D:\IBM\WebSphere\AppServer\profiles\ProcessCommander
javacore.20110511.174141.9628.txt
We need to download IBM Thread Dump Analyzer from here
Start the tool using the following command
E:\tools\jca412>java -Xmx515m -jar jca412.jar
Open the thread dump from
File > Open Thread Dumps
Then click on Analysis > Thread Details.
This will give you details of all the threads.

You might also like