weblogic 设置Stuck Thread Max Time
一、“Stuck Thread Max Time”和“Max Stuck Thread Time”的区别
首先说一下这两个区别：
两个与Stuck Threads时间配置相关的参数.一个在：服务器 – > Some_Server – >配置 – >调整具有以下参数：Stuck Thread Max Time；
其他在：服务器 – > Some_Server – >配置 – > Overload具有以下参数：Max Stuck Thread Time；
调整=卡住线程报告
Servers -> Some_Server -> Configuration -> Tuning -> Stuck Thread Max Time
这将检查任何和所有卡住的线程的Stuck Thread Timer Interval并将其报告给服务器的日志文件,如：’WebLogic.kernel.Default(self-tuning)’一直忙于“zzz”秒工作请求“——”,这比“600”秒的配置时间(StuckThreadMaxTime)多.
过载=卡住线程反应
Servers -> Some_Server -> Configuration -> Overload -> Max Stuck Thread Time
Max Stuck Thread Time指定服务器认为线程卡住的时间长度.如果总计Stuck Thread Count线程卡住,则服务器将自身转换为失败状态.一旦服务器转换为失败状态. “过载”选项卡上的“失败操作”控制要采取的纠正错误的操作.
二、Stuck Thread Max Time
在WEBLOGIC中如果一个线程执行时间超过了Stuck Thread Max Time规定的时间，
WEBLOGIC会把它认为是STUCK线程,并记录在日志中。
我们也可以通过'Dump Thread Stacks' 来捕获STUCK状态的进程。
Home > Summary of Servers > AdminServer>Monitoring>Performance>'Dump Thread Stacks'
但并不是每次'Dump Thread Stacks' 都能捕获Stuck状态的进程。
只有在线程执行时间超过了Stuck Thread Max Time规定的时间
我们才有可能通过'Dump Thread Stacks' 或WEBLOGIC的日志捕获它。
通常我们通过'Dump Thread Stacks'能捕获到以下信息。
"[STUCK] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE native
jrockit.net.SocketNativeIO.readBytesPinned(Native Method)
jrockit.net.SocketNativeIO.socketRead(SocketNativeIO.java:32)
java.net.SocketInputStream.socketRead0(SocketInputStream.java)
java.net.SocketInputStream.read(SocketInputStream.java:129)
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
java.io.BufferedInputStream.read(BufferedInputStream.java:313)
com.informix.asf.IfxDataInputStream.readFully(IfxDataInputStream.java:146)
com.informix.asf.IfxDataInputStream.readSmallInt(IfxDataInputStream.java:453)
在WEBLOGIC的日志中我们能看到如下信息：
<2020-07-08 下午02时38分28秒 CST> <Error> <WebLogicServer> <BEA-000337> <[STUCK]
ExecuteThread: '189' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "635" seconds
working on the request "Http Request: /prpall/business/selectPolicy.do", which is more than the configured
time (StuckThreadMaxTime) of "600" seconds. Stack trace:
java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
java.io.BufferedInputStream.read(BufferedInputStream.java:313)
com.informix.asf.IfxDataInputStream.readFully(IfxDataInputStream.java:146)
com.informix.asf.IfxDataInputStream.readSmallInt(IfxDataInputStream.java:453)
com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2495)
com.informix.jdbc.IfxSqli.a(IfxSqli.java:1752)
com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1704)
com.informix.jdbc.IfxSqli.executeStatementQuery(IfxSqli.java:1635)
com.informix.jdbc.IfxResultSet.a(IfxResultSet.java:206)
com.informix.jdbc.IfxStatement.executeQueryImpl(IfxStatement.java:1229)
com.informix.jdbc.IfxPreparedStatement.executeQuery(IfxPreparedStatement.java:376)
weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:100)
在压力测试阶段为了捕获执行时间长的进程我们可以调整
weblogic中的Stuck Thread Max Time 为一个较小的值。
来捕获并发测试时stuck状态的进程。比如30秒。
通常在产品环境中设置此参数值为600秒。
设置路径为：Home > Summary of Servers > AdminServer >Tuning >Stuck Thread Max Time
11g的路径：
三、出现的相关问题及处理
-
出现这个问题有程序方面、网络方面、weblogic设置方面等等原因。
因为：
- 程序问题，需要项目自己去解决，weblogic在做优化处理也于事无补。
- 网络中断或者认为关闭交互这种情况也不能用weblogic处理（这点我是这么认为的）
说明：
,"weblogic.kernel.Default"是从客户端提交请求后产生的线程所在的队列名。这个队列的线程数默认是15个。如果超过15个线程堵塞，则部署的应用将不能访问。同时后台报：
<XXXX-XX-XX 下午XX时XX分XX秒 CST> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default' has been busy for "1,720" seconds working on the request "Http Request: /myapp/test/index.jsp", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>
线程数(Tread Count)：指派到weblogic.kernel.Default队列的线程数。如果你不需要使用超过15个线程（默认），就不必更改这个属性值。
2.解决方法
如果发送该请求较多，很有可能会导致weblogic的线程阻塞，严重会引起weblogic挂起现象。
可以通过以下几种方法解决：
1）修改StuckThreadMaxTime参数，将默认的600s改成1200s，或者其它适合的值。（路径见截图）
2）增大线程数，防止线程阻塞问题。
3）优化程序，减少处理时间。
