存档

文章标签 ‘rlimit’

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

2009年4月30日 admin 1 条评论

最近一个项目在做压力测试的时候,压力测试人员设置完脚本运行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。