aix cpu java_AIX下was进程占用CPU率较高实例深解析

一朋友求助，生产服务器一台AIX小机WAS进程占用CPU率较高引发频繁报警，而此前该服务器一直正常。

环境：AIX 5.3/WAS6.1

发生故障现象时的截图如下：

问题处理步骤

1、首先通过topas监控可以看到当前占用CPU率较高的那个java进程，记录下进程号：1396916；

2、通过ps -mp 1396916 -o THREAD 以查找当前进程正在占用 CPU 的TID线程信息，把输出信息拷贝到文本文件中；注意查看“CP”列(表示CPU占用率)，看其中哪些线程的此项值比较高并从中挑选出线程。

$ ps -mp 1396916 -o THREAD

USER PID PPID TID ST CP PRI SC WCHAN F TT BND COMMAND

wasuser 1396916 446514 - A 286 60 157 * 202001 - - /usr/was61/WebSphere/AppServer/java/bin/java -Declipse.

- - - 311297 R 63 124 0 - 400000 - - - - - - 372769 S 0 82 1 f100070f10005b40 8410400 - - -

- - - 389319 S 0 60 1 f1000100101f15d8 410400 - - -

- - - 495815 S 0 82 1 f100070f10007940 8410400 - - -

- - - 524499 S 0 82 1 f100070f10008040 8410400 - - -

- - - 573567 S 0 82 1 f100070f10008c40 8410400 - - -

- - - 929945 S 0 82 1 f10002000715d0c8 400400 - - -

- - - 942239 S 0 82 1 f100070f1000e640 8410400 - - -

- - - 991485 S 11 89 1 f100070f1000f240 8410400 - - -

- - - 999521 S 0 70 1 f100070f1000f440 8410400 - - -

- - - 1048809 S 0 82 1 f100070f10010040 8410400 - - -

- - -1061013 R 7160 0 - 400000 - - -

- - - 1064987 S 0 82 1 f100070f10010440 8410400 - - -

- - - 1126635 S 0 82 1 f100070f10011340 8410400 - - -

- - - 1163499 S 0 82 1 f100070f10011c40 8410400 - - -

- - - 3166517 S 0 82 1 f100070f10830540 8410400 - - -

- - - 3285305 S 0 82 1 f100070f10832240 8410400 - - -

- - - 3428667 R 7460 0 - 400000 - - -

- - - 3441043 Z 0 70 1 - c00001 - - -

- - - 3555589 S 0 82 1 f10002000bcab0c8 400400 - - -

- - - 3559823 S 0 82 1 f100070f10836540 8410400 - - -

- - - 3571987 S 0 82 1 f100070f10836840 8410400 - - -

3、通过kill -3 1396916 输出ThreadDump线程执行堆栈快照信息，在/usr/was61/WebSphere/AppServer/profiles/AppSrv01/temp目录中找到类似javacore.20130219.174013.1396916.0012.txt文件，拷贝到本地；

4、下面将PS中占用CPU率较高的这三个线程号311297、 1061013、3428667分别转成16进制的数据(分别为4C001、103095、34513B)，在JAVACORE文件中来对应查找并进行分析。

取4C001在javacore.20130219.174013.1396916.0012.txt中找到下面一段日志：

3XMTHREADINFO "WebContainer : 36" (TID:0x0000000117C92900, sys_thread_t:0x000000011AFD19B8, state:CW, native ID:0x000000000004C001) prio=5

4XESTACKTRACE at sun/awt/color/CMM.cmmColorConvert(Native Method)

4XESTACKTRACE at sun/awt/color/ICC_Transform.colorConvert(ICC_Transform.java:888(Compiled Code))

取103095在javacore.20130219.174013.1396916.0012.txt中找到下面一段日志：

3XMTHREADINFO "WebContainer : 35" (TID:0x0000000115FF2F00, sys_thread_t:0x0000000119F4DA58, state:CW, native ID:0x0000000000103095) prio=5

4XESTACKTRACE at sun/awt/color/CMM.cmmColorConvert(Native Method)

4XESTACKTRACE at sun/awt/color/ICC_Transform.colorConvert(ICC_Transform.java:888(Compiled Code))

取34513B在javacore.20130219.174013.1396916.0012.txt中找到下面一段日志：

3XMTHREADINFO "LT=3:P=496939:O=0:port=9812" (TID:0x0000000116087200, sys_thread_t:0x00000001159DF238, state:CW, native ID:0x000000000012202D) prio=5

java.net.SocketException: Too many open files4XESTACKTRACE at java/net/PlainSocketImpl.socketAccept(Native Method)

4XESTACKTRACE at java/net/PlainSocketImpl.accept(PlainSocketImpl.java:457(Compiled Code))

通过上述跟踪的结果，判定前两段跟踪代码是与图片验证码的生成有关；后一段跟踪代码是与文件句柄有关。

通过查WEB日志和与开发人员沟通，在昨日开发人员更新了图片验证码生成程序，在19日下午又出现用户访问量突增的现象，最终导致该服务器CPU率占用率较高。

5、解决办法:

图片验证码问题：一般网站的会员登录时都要求输入验证码，图片验证码的形式五花八门，但是所使用的原理基本是一样的，都是生成随机字符串，然后描绘成图片的形式输出。验证码的生成主要分两部分：1是随机字符串的生成；2是生成验证码图片。

当使用高级的验证码算法时，会出现几个问题：

1. 生成验证码速度一般是比较慢，也是比较费CPU的。

解决的方法就是预生成验证码，形成一个验证码图片池。

系统每一秒生成一个验证码，同时删除最老的验证码，保证验证码图片池数量是一个常数。要用验证码时随机取一个来用。

2. 高级验证码常常连人都比较难认，对用户体验不好。

采用的方法是，第一次LOGIN登陆不使用验证码，第二次登录失败后再用图片验证码。一般的正常用户，二次之内都能正确LOGIN的。这样就避免了用户频繁刷新的登陆尝试。

这个问题的代码修改交由开发人员完成。

文件句柄问题：

1、查看文件句柄参数

# ulimit -a

time(seconds) unlimited

file(blocks) unlimited

data(kbytes) unlimited

stack(kbytes) 32768

memory(kbytes) 32768

coredump(blocks) 0

nofiles(descriptors) unlimited

$ ulimit -n

unlimited

可以通过#ulimit -n 32768来设置

2、如果需要修改文件句柄的限制

先查看某一个进程(WAS)打开的文件数:

[root@localhost ~]# ps -ef | grep was

wasuser 446514 1 0 Aug 31 - 2912:41 /usr/was61/WebSphere/AppServer/java/bin/java -Declipse.security -Dwas.status.socket=35422 -Dosgi.install.area=/usr/was61/WebSphere/AppServer -Dosgi.configuration.area=/usr/was61/WebSphere/AppServer/profiles/AppSrv01/configuration -Dosgi.framework.extensions=com.ibm.cds -Xshareclasses:name=webspherev61_%g,groupAccess,nonFatal -Xscmx50M -Xbootclasspath/p:/usr/was61/WebSphere/AppServer/java/jre/lib/ext/ibmorb.jar:/usr/was61/WebSphere/AppServer/java/jre/lib/ext/ibmext.jar -classpath /usr/was61/WebSphere/AppServer/profiles/AppSrv01/properties:/usr/was61/WebSphere/AppServer/propert

[root@localhost ~]# lsof -p 446514|wc -l

2729

更改最大打开文件数:

vi修改/etc/security/limits文件配置:

直接修改各定义值。此更改将在系统重新启动后生效。

default:

fsize = -1

core = 0

cpu = -1

data =-1

rss = 65536

stack = 65536

nofiles =32768 #(-1是无限制)

core_hard = 0

root:

nobody:

db2inst2:

core = -1

data = 491519

stack = 32767

rss = -1

fsize = -1

nofiles =10000

补充:

同样的情形，如果是LINUX系统，

1、访问量特别大时候出现 linux的 /tmp目录下 生成不释放文件句柄的 p_w_picpathioxxx.tmp 临时文件。2、具体代码中，JPEG的图片方式比PNG的方式更容易发生 /tmp 目录生成不释放文件句柄的 p_w_picpathioxxx.tmp 临时文件

3、这些 p_w_picpathioxxx.tmp 文件，从服务器ftp下载回来后，直接重新命名为 p_w_picpathioxxx.jpg，即可看到，就是验证码的图片。

最后问题排除。