Collecting Java dumps and core files using the administrative console
With WebSphere Application Server V8, you can produce a Java dump, Java core, or system dump files directly using the administrative console. These files are useful when you have performance issues that you need to analyze, such as memory, thread, and system behaviors.
To collect Java dump and core files, complete the following steps:
Click Troubleshooting > Java dumps and cores
Select the server or servers.
Click System dump, Java core, or Heap dump, as appropriate.
A heap dump is a snapshot of JVM memory. It shows live objects in the memory and references between them.
You can use this option to debug conditions such as memory leaks, heap fragmentation or to investigate what objects are consuming the largest part of the memory.
Use this button to investigate why a server is hanging or investigate messages in the logs that indicate a thread has not completed its work in the expected amount of time.
Use this button to generate system native dumps of the server process. These dumps can be quite large.
How to manually generate a Thread Dump in WebSphere Application Server using wsadmin scripting
Navigate to the profile's
test317:~ # cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin/ test317:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin #
Connect to deployment manager using wsadmin script:
test317:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin # ./wsadmin.sh -lang jython WASX7209I: Connected to process "dmgr" on node test317CellManager01 using SOAP connector; The type of process is: DeploymentManager WASX7031I: For help, enter: "print Help.help()"
If security is enabled or the default SOAP ports have been changed, you will need to pass additional parameters to the batch file in order to get a wsadmin prompt. For example:
./wsadmin.sh [-host host_name] [-port port_number] [-user username [-password password]]
Note: You can connect wsadmin to any of the server JVM in the cell. After running the wsadmin command it will display the server process for which it has attached to. Depending on the process that it has attached to, you can get thread dumps for various JVMs. If wsadmin is connected to deployment manager, then you can get thread dumps for any JVM in that cell. If it is attached to a node agent, then you can get thread dumps for any JVM in that Node. If it is attached to a server, then you can get thread dumps only for the server to which has connected to.
Get a handle to the problem application server.
wsadmin>serverJVM = AdminControl.queryNames("type=JVM,process=server1,*")
server1 is the name of the application server that does not respond (or is hung). If
wsadmin is connected to a Deployment Manager and if the server names in the cell are not unique, then
you can qualify the JVM with node attribute in addition to process:
wsadmin>serverJVM = AdminControl.queryNames("type=JVM,process=server1,node=nodeName,*")
Generate multiple javacores by issuing the following command:
wsadmin>AdminControl.invoke(serverJVM,"dumpThreads") '' wsadmin>AdminControl.invoke(serverJVM,"dumpThreads") ''
The results are as follows:
ilcbuild@test317:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01> ls -l javacore* -rw-r--r-- 1 root root 2159401 Jul 6 13:20 javacore.20130706.132009.58067.0003.txt -rw-r--r-- 1 root root 2159011 Jul 6 13:21 javacore.20130706.132105.58067.0004.txt
To analyse Thread Dump download the IBM Thread and Monitor Dump Analyzer for Java Technology.