本文共 4948 字，大约阅读时间需要 16 分钟。
一朋友求助，生产服务器一台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 71 60 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 74 60 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=54XESTACKTRACE 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) unlimitedfile(blocks) unlimiteddata(kbytes) unlimitedstack(kbytes) 32768memory(kbytes) 32768coredump(blocks) 0nofiles(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 = 0root:
nobody:
db2inst2:
core = -1 data = 491519 stack = 32767 rss = -1 fsize = -1 nofiles =10000补充:
同样的情形，如果是LINUX系统，1、访问量特别大时候出现 linux的 /tmp目录下 生成不释放文件句柄的 imageioxxx.tmp 临时文件。最后问题排除。
转载地址：http://sqzaa.baihongyu.com/