一次因为系统参数而导致的WAS无响应

首页 > Websphere系列, 排错 > 一次因为系统参数而导致的WAS无响应

2009年4月30日 admin 发表评论阅读评论

最近一个项目在做压力测试的时候，压力测试人员设置完脚本运行8小时后，第二天总会发现虽然脚本运行正常，但是有一个节点上的Server没有相应。查看日志说日志没有任何报错，记录的最后一条总是前一天的半夜。因为半夜正好是做批处理的时候，一开始怀疑是否是这导致的宕机，但是停掉批处理程序后依旧发生这种现象（而且是在下班时刻发生），也就排除了这个可能。

下面是我的排错经过：

查看无法提供服务的app2的systemout.log日志，发现从昨天晚上5点09分后，没有新的日志输出。最后的日志为

[4/15/09 17:09:28:193 GMT+08:00] 00000953 IncidentStrea W com.ibm.ws.ffdc.IncidentStreamImpl write FFDC0013I: FFDC failed to write to incident stream file /was/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/ffdc/APP2_44ca44ca_09.04.15_17.09.28_0.txt, caught exception java.lang.NullPointerException

查看system.err文件，没有发现有价值的内容

于是查看ffdc目录下的17：09生成的日志，在APP2_7b2c7b2c_09.04.15_17.09.27_0.txt中发现有Stack Dump = javax.imageio.IIOException: Can’t create output stream!信息。

在APP2_2e542e54_09.04.15_17.09.27_1.txt中发现有Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: java.net.SocketException: Too many open files; targetException=java.lang.IllegalArgumentException: Error opening socket: java.net.SocketException: Too many open files]

于是使用ulimit –a命令查看AIX的limit参数

APP2:/was/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/ffdc#ulimit -a
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000

发现一个进程可以打开的最大文件数为2000.

用ps –ef | grep java命令找到app2的sid，然后用procfiles sid命令查看app2的进程现在打开了多少文件

APP2:/was/IBM/WebSphere/AppServer/profiles/AppSrv01/bin#procfiles 815304

815304 : /was/IBM/WebSphere/AppServer/java/bin/java -Declipse.security -Dwas.status.sock

Current rlimit: 2000 file descriptors

………………

1993: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1994: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1995: S_IFREG mode:0444 dev:10,15 ino:160745 uid:0 gid:0 rdev:0,0

O_RDONLY size:15694

1999: S_IFREG mode:0444 dev:10,15 ino:164300 uid:0 gid:0 rdev:0,0

O_RDONLY size:1042

打开文件数已经到达2000，于是app2无法创建新的systemout.log日志文件，也就无法再提供服务。

由此分析得AIX的nofiles参数对于websphere来说不够大（对于Hp-ux，安装前调整系统参数时就需要把maxfiles调整为8192，但是AIX内核是自调整，所以IBM安装要求上没有提到需要手动修改什么参数）特别是在压力测试时候，短时间内的积累可能会达到2000的限制，实际生产环境中也可能会遇到如此情况，当然集群中另外一台APP跑的好好的也挺让人奇怪。

接下来就是调整ulimit中的nofiles限制到4096，然后重启nodeagent，再由控制台重启app即可。当然也可以直接用命令重启app，但是因为nodeagent没有重启过，环境变量没有生效，下次在控制台中重启app后nofiles依旧会被限制在2000。