cpu占用过高一例

http://xjsunjie.blog.51cto.com/999372/1136156

环境: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=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 files
4XESTACKTRACE          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目录下 生成不释放文件句柄的 imageioxxx.tmp 临时文件。 
2、 具体代码中,JPEG的图片方式比PNG的方式更容易发生 /tmp 目录生成不释放文件句柄的 imageioxxx.tmp 临时文件
3、这些 imageioxxx.tmp 文件,从服务器ftp下载回来后,直接重新命名为 imageioxxx.jpg,即可看到,就是验证码的图片。
最后问题排除。

你可能感兴趣的:(cpu)