今天ST的server出现了异常，在网上搜索出下面的文章，觉得比较有用。
出处：http://bbs.weblogicfans.net/archiver/tid-3186.html
一次weblogic 频繁hang处理过程
[i=s] 本帖最后由 jw_gyl56 于 2010-12-10 11:18 编辑 [/i]
[b]故障现象简要描述：[/b]
应用服务器经常业务期间down掉，业务期间应用服务器需要频繁重启，连接池经常被占满，同时数据库实例的process被用完。
环境：Weblogic814 for aix
[b]应急处理措施：[/b]
手工重启服务
[b]分析与处理过程：[/b]
应用服务器jdbc连接池经常被占满，同时数据库实例的process被用完。业务界面无法登陆。需要重启weblogic服务才可以。
检查故障时间点的weblogic 日志：
<Aug 30, 2009 8:33:48 AM GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '37' for queue: 'weblogic.kernel.Default' has been busy for "1,880" seconds working on the request "Http Request: /web/WEB-JSP/sfzw/sfgl/wait.gif", which is more than the configured time (StuckThreadMaxTime) of "1,600" seconds.>
<Aug 30, 2009 8:33:48 AM GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '59' for queue: 'weblogic.kernel.Default' has been busy for "1,879" seconds working on the request "Http Request: /web/WEB-JSP/sfzw/sfgl/wait.gif", which is more than the configured time (StuckThreadMaxTime) of "1,600" seconds.>
<Aug 30, 2009 8:33:48 AM GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '66' for queue: 'weblogic.kernel.Default' has been busy for "1,820" seconds working on the request "weblogic.rmi.internal.dgc.DGCClientImpl$HeartBeat@127d40b1", which is more than the configured time (StuckThreadMaxTime) of "1,600" seconds.>
[color=red]注意日志中的红色部分，发现报BEA-00337错误，which is more than the configured time (StuckThreadMaxTime) of "1,600" seconds 这是一个StuckThread超时错误。
WebLogic Server 提供 stuckThreadMaxTime 及stuck Thread Timer Interval 两个参数协助监测 thread stuck 的状况并发出警告 , stuckThreadMaxTime 的 default 值为600 秒 , stuckThreadTimerInterval 的 deault 值也是 600 秒（应用设置的为1600s） 每 600 秒 WebLogic Server会检查 Queue 中所有的 thread, 如果发现有持续工作 600 秒的情况发生 ,Server 认为这个 thread 的状态为 stuck, stuck 住的 thread 在 Server log 中会有记录 , 如果情況恶化 ,stuck thread 数量越来越多 , 造成 WEBLogic Server 的 Default Execute Queue 中的 thread 全部 stuck,导致Server hang住。[/color]#cat nohup.out |grep BEA-000337 >jw.txt ----统计一下日志中所有BEA-000337的错误发现从11日到30,中间也报过类似的错误。
错误说明：
经过metalink查询，这是Weblogic在AIX的JVM上由来已久的bug，从8.1.4就开始在不同版本间出现,该bug会导致StuckThread超时，java.net.SocketOutputStream.socketWrite0,从而导致java进程hang住。
原因是IBM的JVM底层socket实现和weblogic配合问题，需要打patch CR370915.jar解决
详细请参考metalink Doc ID: 788518.1
同时打开weblogic连接池监控日志，步骤如下：
登录weblogic console, %Domain% -> Services -> JDBC -> Connection Pools -> jdbc/ioa
Configuration页 -> Connection, 点开Advanced Options, 修改以下配置项状态：
配置项名称 默认值 修改为 说明
Enable Connection Leak Profiling 禁用 启用 开启连接池泄漏的监控。
Enable Connection Profiling 禁用 启用 开启连接池监控。
Inactive Connection Timeout 0 100 连接在指定时间内（单位：秒）没有活动的话，WebLogic会将之释放并回收
以上配置项修改后不需要重启服务器或应用。(备注:该日志监控打开后weblogic后台会做debug诊断，测试发现对应用系统性能影响较大，不建议经常开启，只是在故障频繁时作为诊断使用)
该日志会生成在$WEBLOGIC_HOME/user_projects/domains/mydomain/$Server/$Server.log 文件中。
/beawlsp4/user_projects/domains/mydomain/Server1/Server1.log --对应日志
查看对应的日志：
Aug 31, 2009 2:22:06 PM GMT+08:00> <Warning> <JDBC> <zzyxapp02> <Server2> <Finalizer> <<anonymous>> <> <BEA-001074> <A JDBC pool connection leak was detected. A connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by the garbage collector and returned to the connection pool. The following stack trace at create shows where the leaked connection was created. Stack trace at connection create:
注意上面红色部分，<BEA-001074> <A JDBC pool connection leak was detected 日志监测到连接池溢出。对应的程序方法为：
at dlyx.yygl.yykc.JlzzfaAction.isSetPowerInfo(JlzzfaAction.java(Compiled Code))
at dlyx.yygl.yykc.JlzzfaAction.init(JlzzfaAction.java(Compiled Code))
让开发检查对应的程序发现有打开数据库但是没有关闭的连接调用。
连接池溢出会导致短时间内从应用程序到数据库的大量死连接堆积，这样的结果一是应用服务器挂起，另一个就是数据库processes被占满。同时weblogic 日志里会报<Error> <JDBC> <zzyxapp02> <Server2> <ExecuteThread: '42' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-001112> <Test "SELECT 1 FROM DUAL" set up for pool "thin_dlyx2" failed with exception: "java.sql.SQLException: No more data to read from socket".> 此时已经建立不了连接也取不到任何数据。
同时还发现日志里报很多的Too many open files日志
####<Aug 31, 2009 3:03:39 PM GMT+08:00> <Critical> <WebLogicServer> <zzyxapp01> <proxyServer> <ListenThread.Default> <<WLS Kernel>> <> <BEA-000204> <Failed to listen on port 6001, failure count: 1, failing for 0 seconds, java.net.SocketException: Too many open files>
####<Aug 31, 2009 3:03:40 PM GMT+08:00> <Notice> <WebLogicServer> <zzyxapp01> <proxyServer> <ListenThread.Default> <<WLS Kernel>> <> <BEA-000205> <After having failed to listen, the server is now listening on port 6001.>
####<Aug 31, 2009 3:03:41 PM GMT+08:00> <Critical> <WebLogicServer> <zzyxapp01> <proxyServer> <ListenThread.Default> <<WLS Kernel>> <> <BEA-000204> <Failed to listen on port 6001, failure count: 1, failing for 0 seconds, java.net.SocketException: Too many open files>
[color=red]
BEA-000204 Failed to listen on port 6002, failure count: 3, failing for 3 seconds, java.net.SocketException: Too many open files 这个错误应该是应为连接池被占满了反复尝试open 文件导致的，解决了连接池的问题，这个问题应该不会再报，但是这个错误也反应了weblogic的默认打开文件数量应该没有更改。对于生产系统，建议修改默认的打开文件数量。
通过java dump的日志可以看到默认的限制为 XHUSERLIMIT RLIMIT_NOFILE : 1024[/color]
针对以上问题对应用服务器做了以下修改:
1、调整操作系统ulimit
ulimit -n 8192 ---设置最大打开文件数8192
2、调整commEnv.sh设置resetFd
修改 /beawlsp4/weblogic81/common/bin/commEnv.sh 文件
# resetFd
ulimit -n 8192
bea默认的最大打开文件数为1024，设置为8192
该设置主要针对日志里报出来的<BEA-000204> 错误
<BEA-000204> <Failed to listen on port 6002, failure count: 2, failing for 1 seconds, java.net.SocketException: Too many open files
3、打CR370915补丁
补丁文件8173442_810sp4.jar
具体方法:上传8173442_810sp4.jar到/beawlsp4/weblogic81/server/lib目录下
修改：/beawlsp4/user_projects/domains/mydomain/startWebLogic.sh中的内容
CLASSPATH="${WEBLOGIC_CLASSPATH}:${POINTBASE_CLASSPATH}:${JAVA_HOME}
/jre/lib/rt.jar:${WL_HOME}/server/lib/webservices.jar:${CLASSPATH}"
CLASSPATH="${WL_HOME}/server/lib/CR237198_810sp4.jar:${CLASSPATH}"
export CLASSPATH
为:
CLASSPATH="${WEBLOGIC_CLASSPATH}:${POINTBASE_CLASSPATH}:${JAVA_HOME}
/jre/lib/rt.jar:${WL_HOME}/server/lib/webservices.jar:${CLASSPATH}"
CLASSPATH="${WL_HOME}/server/lib/CR237198_810sp4.jar:${WL_HOME}/server
/lib/8173442_810sp4.jar:${CLASSPATH}"
export CLASSPATH
重启weblogic服务
---主要针对BEA-000337错误
调整后应用恢复正常！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
