Weblogic宕机事件定位分析

Weblogic宕机事件定位分析

Weblogic宕机事件定位分析

段常飞

Weblogic宕机,是很多运维人员的噩梦，时不时的系统挂了，而且总是找不到源头，开发说程序没有大的变动，一直很平稳呀，客户反馈，系统硬件配置已经相当高了，足以支持系统运行呀。又把问题抛给了运维人员，必须得找出原因了。可是怎么下手呢？

下面我以郑州为例来演示如何定位程序问题。

郑州市20160505、20160509宕机事件日志

错误类型：

<2016-5-9 上午11时22分13秒

CST><Error><WebLogicServer><BEA-000337><[STUCK] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "3,708" seconds working on the request "Workmanager: default, Version: 0, Scheduled=true,

Started=true, Started time: 3708125 ms

[

Cookie:

JSESSIONID=yGn2XvYC6yV3nDLJHCQFyxVQLSBcpL1WmRxkhQl78nyZTpq13 J8v!-154976378; BIGipServerPool-zhongxinduan=1348708544.37919.0000

]", which is more than the configured time (StuckThreadMaxTime) of "3,600" seconds. Stack trace:

com.neusoft.udolink.OPSysManager.start(OPSysManager.java:361)

2016/05/09-11:24:21 >> INFO >> Timer-3 >> http://www.77cn.com.cnp.cacheSynchronize.CacheTask.run(CacheTask.java:34) >>检查内存更新...

<2016-5-9 上午11时24分21秒CST><Warning><Socket><BEA-000449><Closing socket as no data read from it on 192.168.99.251:39,310 during the configured idle timeout of 5 secs>

<2016-5-9 上午11时26分28秒CST><Warning><Socket><BEA-000449><Closing socket as no data read from it on 192.168.99.80:24,574 during the configured idle timeout of 5 secs>

<2016-5-9 上午11时26分28秒CST><Warning><Socket><BEA-000449><Closing socket as no data read from it on 192.168.99.80:24,539 during the configured idle timeout of 5 secs>

分析原因：weblogic的线程阻塞，进而导致批量等待阻塞，最纵引起weblogic挂起现象

Weblogic宕机事件定位分析

Weblogic 线程处理的默认时间为3600s，StuckThreadMaxTime:3600。在运行一些将长时间的程序时经常会由于请求时间过长，导至超时。报出more than the configured time (StuckThreadMaxTime) of "3600" seconds错误。或是由于发送该请求较多（业务重复办理，后台并没有中断），达到很有可能会导致weblogic的线程阻塞，无法释放系统资源，严重引起weblogic挂起现象。

解决方法通常可以如下：

1:优化报错执行的程式，检查是个执行3600s的程式是否可优化或是可拆分，此种解决方法较佳，这是解决问题的根本。

2:调整StuckThreadMaxTime时间，将3600s调成更大。此方法虽然可以解决线程请求时间，但容易至使等待线程过多，或致使线程阻塞，严重会引起weblogic 挂起致使Down机。目前已经相当长了，通过weblogic监控到，目前平均每个服务等待的线程占一半还多。这个值不建议再增加。

3:增大线程数，防止线程阻塞问题。但前提条件是硬件需要支持。现在系统线程数量由weblogic11自动调节已经够大，不是瓶颈。不建议调整。

通过上述分析，最好的还是从根本上解决问题，就是找出应用程序中长时间调用等待的action，通过日志及监控系统运行分析查找；

1、查看服务器健康情况：

服务器健康状况: Warning

原因: ThreadPool has stuck threads

提示已经有阻塞的线程。

2、查找阻塞的线程：

从线程中去查找。

Weblogic宕机事件定位分析

Workmanager: default, Version: 3, Scheduled=true, Started=true, Started time: 17531526 ms [ POST /eapdomain/EmpPatchReceAction.do? HTTP/1.1 Accept-Language: zh-cn Accept-Encoding: gzip, deflate Application-Name: APP_BASED_UNIEAP Content-Type: application/x-www-form-urlencoded Content-Length: 154 User-Agent: 基于UniEAP的应用Cache-Control: no-cache Cookie: JSESSIONID=gLnfXzWS6vK8zdrwvdtpyxwM06m660Zrhx1X1JkJCX1VQnRVh13r!1936764830; BIGipServerPool-zhongxinduan=1348708544.37919.0000

根据上述提示可以查找到对应的action，已经执行的时间17531秒，已经阻塞了。

3、在程序中跟踪这个EmpPatchReceAction,EmpPatchReceApplogic:

批然后再查看调用的那个方法，只能看内存里面的信息了：

从Thread Dump里面找到会话的阻塞线程：

"[STUCK] ExecuteThread: '19' for queue: 'weblogic.kernel.Default

(self-tuning)'" RUNNABLE native

http://www.77cn.com.cnmon.impl.StoredProcedureImpl.execute(StoredProcedu reImpl.java:206)

com.neusoft.unieap.util.winclient.SqlUtil.executeStoredProcedure(SqlU til.java:393)

http://www.77cn.com.cnmon.fee.adjust.impl.EmpPatchReceManag eApplogic.auditUnitLateFeeProcess_pch(EmpPatchReceManageApplogic.java

Weblogic宕机事件定位分析

:795)

http://www.77cn.com.cnmon.fee.adjust.impl.EmpPatchReceApplo

gic.auditCancal(EmpPatchReceApplogic.java:1174)

http://www.77cn.com.cnmon.fee.adjust.impl.EmpPatchReceInter

action.auditCancal(EmpPatchReceInteraction.java:1352)

http://www.77cn.com.cnmon.fee.adjust.impl.EmpPatchReceActio

n.auditCancal(EmpPatchReceAction.java:670)

sun.reflect.GeneratedMethodAccessor182.invoke(Unknown

Source)

从上面分析，找到了吗：

http://www.77cn.com.cnmon.fee.adjust.impl.EmpPatchReceManag

eApplogic.auditUnitLateFeeProcess_pch(EmpPatchReceManageApplogic.java

:795)

http://www.77cn.com.cnmon.fee.adjust.impl.EmpPatchR

eceApplogic.auditCancal(EmpPatchReceApplogic.java:1174) …… 此处隐藏：3779字，全部文档内容请下载后查看。喜欢就下载吧 ……