Coming to step by step
learning:
--------------------------------
What
is Thread dump?
Thread Dump is a
textual dump of all active threads and monitors of Java apps running in a
Virtual Machine.
When
we will take Thread dump? (Scenarios)
1. Scenario 1: when server is hang Position, i.e. that time
server will not respond to coming requests.
2. Scenario
2: While sever is
taking more time to restart
3. Scenario 3: When we are Getting exception like
“java.lang.OutOfMemoryException”
4. Scenario 4: Process running out of File descriptors.
Server cannot accept further requests because sockets cannot be created
5. Scenario
5: Infinite Looping
in the code
How
many ways take Thread Dumps?
Many types we have to
take a Thread dumps. As per your flexibility you can choose one Procedure. For
analyzing take dumps some Intervals (like every 10mins, 10mins etc.).
Generating
Dump Talking Procedures
1. Take Thread dump from Console by Using of
below command
$kill -3 PID
(For
Getting PID, Use this Command ps –ef | grep “java”)
Here The Output of the
Thread Dump will be generated in the Server STDOUT.
(Note: If a process is
not responding to kill -3 then it’s a JVM bug.)
2. Generation Thread Dump via Admin Console
a. login to
Admin Console(with Admin Username/Password)
b. Click on
Server, after choose your server
c. Goto
Monitoring TAB
d. Goto Threads
TAB, after click on “Dump Thread Stack” Button
e. Now you can
view the all the Threads in Same page
f. Copy and
paste in a txt file.
3. We can Collect Thread Dump Using “WebLogic.Admin” which is deprecated, but still available
or may be available in near future as well As i think because it is one of the
best debugging utility for Admins.
java WebLogic.Admin -url t3://hostname: port -username Weblogic -password
Weblogic THREAD_DUMP
This Thread Dumps will be generated in Servers
STDOUT file
4. Getting Thread Dumps by using Jstack Utility
a.jstack –m (to connect to a live java process)
b. jstack –m [server_id@]
(to connect to a remote debug server)
(-m
Means print both java and native frames (mixed mode))
5. By Using WLST Script, can contain extension
of (.py)
connect(‘weblogic’,'weblogic’,'t3://hostname:port′) cd
(”Servers’) ls()cd (‘AdminServer’) ls() threadDump()
Execute
this Script in console.
What
can I Analysis with Thread Dumps?
We need to analyze the
thread dumps for analyzing running threads and their states to identifying.
How
can I analysis thread dumps?
For analyze thread
dumps we have lots of tools to understand easily thread states
1. samurai
tool :
In
this tool you can identify all the Thread states by
identifying colors. We need to take care about
Deadlocks and waiting state threads.
More
Details:
$ java -jar samurai.jar
After running we will get a Screen like below
Goto Thread dump tab
When Samurai detects a thread dump in your log, a tab named "Thread
Dump" will appear.
You can just
click "Thread dumps" tab to see the analysis result. Samurai colors
idle threads in gray, blocked threds in red and running threds in green. There
are three result views and Samurai shows "Table view" by default. In
many case you are just interested in the table view and the sequence view. Use
the table view to decide which thread needs be inspected, the sequence view to
understand the thread's behavior. You should takecare especially threds always
in red.
2. TDA
Tool :
Actions
taken for Issue resolving
1. Classic Dead
Locks : Look for the threads
waiting for monitor entry
For Example :
"ExecuteThread:
'95' for queue: 'default'" daemon prio=5 tid=0x411cf8 nid=0x6c waiting for
monitor entry [0xd0f80000..0xd0f819d8]
at weblogic.common.internal.ResourceAllocator.release(ResourceAllocator.java:766)
at weblogic.jdbc.common.internal.ConnectionEnv.destroy(ConnectionEnv.java:590)
Reason: The above thread is waiting to acquire lock on
Resource Allocator object. The next step is to identify the thread that is
holding the Resource Allocator object
"ExecuteThread:
'0' for queue: '__weblogic_admin_rmi_queue'" daemon prio=5 tid=0x41b978
nid=0x77 waiting for monitor entry [0xd0480000..0xd04819d8]
at weblogic.jdbc.common.internal.ConnectionEnv.getPrepStmtCacheHits(ConnectionEnv.java:174)
at
weblogic.common.internal.ResourceAllocator.getPrepStmtCacheHitCount
(ResourceAllocator.java:1525)
Reason: This thread is holding lock on source
Allocator object, but is waiting for Connection Env object. This is a classic
deadlock.
A sample
dump:
"ExecuteThread:
'10' for queue: 'SERV_EJB_QUEUE'" daemon prio=5 tid=0x005607f0 nid=0x30 in
Object.wait() [83300000..83301998]
at
java.lang.Object.wait(Native Method)
- waiting on (a
weblogic.ejb20.pool.StatelessSessionPool)
at
weblogic.ejb20.pool.StatelessSessionPool.waitForBean(StatelessSessionPool.java:222)
Reason: The above thread would come out of wait()
under two conditions
(Depending on
application logic)
1) One of the thread
available in the execute queue pool would call notify() on this object when an
instance is available. (If the wait() is indefinite).
This can
cause the thread to hang for ever if server never does a notify() to this object.
2) If the timeout
exceeds, the thread would throw an exception and back to execute queue thread
pool.