Troubleshooting WebLogic Server 12c - Oracle WebLogic Server 12c Advanced Administration - page 195

Before starting to analyze the thread dumps, use the procedure from the
last recipe and monitor the heap usage. When the JVM is spending too
much CPU time on garbage collections, the incoming requests can pile up
as well, raising the QueueLength attribute of the thread pool.
The thread dump is one of the most guaranteed methods of troubleshooting a Managed
Server. Normally, you need to observe only the threads from the self-tuning thread pool. The
thread stack trace from the self-tuning thread pool can have the [ACTIVE] , [STANDBY] , and
[STUCK] flags, and it has the following pattern:
"[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'" id=39 idx=0x80 tid=4952 prio=5 alive, waiting, native_
blocked, daemon
-- Waiting for notification on: weblogic/work/
ExecuteThread@0xf06a43b0
[...]
at weblogic/work/ExecuteThread.run()
Take some thread dumps in a sequence with a short interval between them. There is no
specific formula for how many thread dumps to take or which interval to use. Sometimes, only
one thread dump is sufficient.
A thread dump analysis requires certain knowledge of Java coding, but it is
the most important tool to identify what is going on inside WebLogic.
In this scenario, the sequence of thread dumps reveals that almost all threads are stopped at
the following stack:
"[ACTIVE] ExecuteThread: '10' for queue: 'weblogic.kernel.Default
(self-tuning)'" id=166 idx=0x2a4 tid=25647 prio=1 alive, in native,
daemon
at jrockit/net/SocketNativeIO.readBytesPinned()
[...]
at oracle/jdbc/driver/OraclePreparedStatement.execute()
[...]
at oracle/jdbc/driver/OraclePreparedStatementWrapper.execute()
at weblogic/jdbc/wrapper/PreparedStatement.execute()
at com/myapp/db/DBUtil.executeQuery()
[...]
at weblogic/work/ExecuteThread.execute()
at weblogic/work/ExecuteThread.run()