Monday, April 18, 2011

Taking Thread Dump in Linux

Generating a Thread Dump on Linux, including Solaris and other Unixes

1.) Identify the java process that JIRA is running in: This can be achieved by running a command similar to:

[root@server2~]#ps -ef | grep java
root      8876  8854 12 10:54 pts/5    00:08:37 /usr/jdk1.6.0_16/bin/java -Dprogram.name=run.sh -server -Xms256m -Xmx1024m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/data2/jboss/lib/endorsed -classpath /data2/jboss/bin/run.jar:/usr/jdk1.6.0_16/lib/tools.jar org.jboss.Main -c all -b 192.168.2.102 -Djboss.messaging.ServerPeerID=1
root     10154  9577  0 12:02 pts/3    00:00:00 grep java
 

2.) Find the process ID of the JVM and use the ps command to get list of all processes: 

kill -3 
The thread dump will be printed to Confluence's standard output.
 
Output will be something Like this:
Full thread dump Java HotSpot(TM) Server VM (14.2-b01 mixed mode):

"RMI TCP Connection(idle)" daemon prio=10 tid=0x09c19c00 nid=0x2776 waiting on condition [0x5f76f000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x6d21b708> (a java.util.concurrent.SynchronousQueue$TransferStack)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
        at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)
        at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
        at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:619)

"OOB-104,192.168.2.102:56221" prio=10 tid=0x62c7b000 nid=0x2764 waiting on condition [0x5eb69000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x75208848> (a java.util.concurrent.SynchronousQueue$TransferStack)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
        at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:422)
        at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
        at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:857)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:619)

 
!Enjoy
Kuldeep Sharma 

No comments:

Post a Comment

Kubernetes 1.31 || Testing the Image Volume mount feature using Minikube

With Kubernetes new version 1.31 ( https://kubernetes.io/blog/2024/08/13/kubernetes-v1-31-release/ ) there are so many features releases for...