websphere服务器cpu使用率较高原因定位分析

今天下午17点时，正准备收拾东西回家，负责主机维护的同事告诉我，was服务器cpu使用率较高，很长时间了一直是80%以上，让我分析一下原因，连上去topas一把，果然有明显异常，在这里记录一下处理过程。

方法一：过程+javacore文件分析

第一步：
    跟据topas首先确认使用率较高的进程 pid:397376

第二步：

    跟据pid确认该进程是什么

    ps -ef | grep 397376

    结果发现是was控制台上的应用进程

第三步：

    查找当前进程正在占用cpu和TID线程信息

    注意："CP"列表示cpu占用率，从输出结果中挑出值比较高的线程

    ps -mp 1396916 -o THREAD

    USER    PID   PPID      TID S  CP PRI SC    WCHAN        F     TT BND COMMAND
    root 397376 651454        - A 457  60 187        *   202001      -   - /usr/IBM/WebSphere/AppServer/java/bin/java -Declipse.security -Dwas.status.socket=59352 -D
       -      -      -   479381 S   0  62  1 f100070f10007540  8410400      -   - -
       -      -      -   495825 R   9  88  0        -   400000      -   - -
       -      -      -   528557 S   0  82  1 f100070f10008140  8410400      -   - -
       -      -      -   614401 S  12  90  1 f10006000cf700c8   400400      -   - -
       -      -      -   888909 S   0  82  1 f100070f1000d940  8410404      -   - -
       -      -      -   921739 S  11  89  1 140e617c8   c10400      -   - -
       -      -      -   987333 S   1  82  1 f100070f1000f140  8410400      -   - -
       -      -      -  1355809 S   0  82  1 f100070f10014b40  8410400      -   - -
       -      -      -  1462449 S   0  82  1 f100070f10016540  8410400      -   - -
       -      -      -  1466577 S   9  88  1 140e617c8   c10400      -   - -
       -      -      -  1495167 S  10  60  1 f1000600102e20c8   400400      -   - -
       -      -      -  1507509 R   9  60  0        -   400000      -   - -
       -      -      -  1556565 S   0  82  1 f100070f10017c40  8410404      -   - -
       -      -      -  1568827 R   9  88  1 140e617c8   c00000      -   - -
       -      -      -  1650789 R  12  90  0        -   400000      -   - -
       -      -      -  1659135 S  11  89  1 140e617c8   c10400      -   - -
       -      -      -  1663009 R  13  90  0        -   400000      -   - -
       -      -      -  1785981 R  10  88  1 140e617c8   c00000      -   - -
       -      -      -  1818741 S   0  82  1 f100070f1001bc40  8410400      -   - -
       -      -      -  1835013 R   8  60  0        -   400000      -   - -
       -      -      -  1871873 S   0  62  1 f100070f1001c940  8410400      -   - -
第四步：

    通过kill -3 397376输出ThreadDump线程执行堆栈快照信息，该命令会生成一个javacore文件，该文件的

    具体位置在/usr/IBM/WebSphere/AppServer/profiles/AppSrv01/

   注意，是kill -3 写就kill -9区别哦

第五步：将ps中占用CPU率较高的这三个线程号614401、 921739、1495167分别转成16进制的数据(分别为

    96001、e108b、16d07f)，在JAVACORE文件中来对应查找并进行分析

第六步：假如跟据16d07f查找javacore文件中的内容，找以具体的代码如下：

 "WebContainer : 278" (TID:0x0000000120F3ED00, sys_thread_t:0x0000000121DE1E98, state:B, native ID:0x000000000016D07F) prio=5              
    at com/talkweb/ecm/prebill/dao/impl/PrebillInstanceDaoImpl.getPrebillInstanceEntityById(PrebillInstanceDaoImpl.java:207(Compiled Code))
    at com/talkweb/ecm/prebill/service/impl/PrebillServiceImpl.getPrebillInstanceEntityById(PrebillServiceImpl.java:155(Compiled Code))   
    at com/talkweb/ecm/prebill/action/PrebillIreportAction.exportExcelDataOfDiary(PrebillIreportAction.java:455(Compiled Code))  

第七步：exportExcelDataOfDiary  跟据这个方法来看，应该是有用户导出数据到excel所致，因我只负责维护，业务上的操作不太懂，只能交给项目组开发的同事去分析，下周一上班后询问开发代码上存在什么问题。

    参考网络技术文档地址： http://xjsunjie.blog.51cto.com/999372/1136156

                           http://jxstar.iteye.com/blog/1464179

方法二：只分析javacore文件 

    其实只有javacore文件，运用javacore分析工具也可以定位到具体的代码，方法如下：

运用jvm内存溢出分析工具，打开javacore文件后，我们可以看到线程状态如下：

从图上看，有20个线程是Blocked状态，找到blocked进程，对比分析后发现，20个blocked进程都被同一个类中的方法阻塞，如下图所示：

     我们同样定位到同一个类中的方法exportExcelDataOfDiary ，好像第二种方法要比第一种方法效率更高，更快，但是我想有些情况仅仅只有javacore文件是无法定位的，方法二当做方法一的备用方法，当然方法比较直观，在实际工作中需要灵活运用即可。