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

was服务器cpu使用率较高，很长时间了一直是80%以上，分析原因，连上去topas一把，果然有明显异常，在这里记录一下处理过程。

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

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

第二步：

   跟据pid确认该进程是什么

   ps -ef | grep397376

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

第三步：

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

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

   ps -mp 1396916 -oTHREAD

   USER   PID  PPID     TID S  CP PRISC   WCHAN       F    TT BND COMMAND
    root 397376651454       - A 457  60187       *  202001     -   -/usr/IBM/WebSphere/AppServer/java/bin/java -Declipse.security-Dwas.status.socket=59352 -D
      -     -     -   479381S   0 62  1 f100070f10007540 8410400     -   - -
      -     -     -   495825R   9 88 0       -  400000     -   - -
      -     -     -   528557S   0 82  1 f100070f10008140 8410400     -   - -
      -     -     -   614401 S 12 90  1f10006000cf700c8  400400     -   - -
      -     -     -   888909S   0 82  1 f100070f1000d940 8410404     -   - -
      -     -     -   921739 S 11 89  1140e617c8  c10400     -   - -
      -     -     -   987333S   1 82  1 f100070f1000f140 8410400     -   - -
      -     -     -  1355809 S  0  82  1f100070f10014b40 8410400     -   - -
      -     -     -  1462449 S  0  82  1f100070f10016540 8410400     -   - -
      -     -     -  1466577 S  9  88  1140e617c8  c10400     -   - -
      -     -     -  1495167 S  10 60  1f1000600102e20c8  400400     -   - -
      -     -     -  1507509 R  9  60 0       -  400000     -   - -
      -     -     -  1556565 S  0  82  1f100070f10017c40 8410404     -   - -
      -     -     -  1568827 R  9  88  1140e617c8  c00000     -   - -
      -     -     -  1650789 R  12 90 0       -  400000     -   - -
      -     -     -  1659135 S  11 89  1140e617c8  c10400     -   - -
      -     -     -  1663009 R  13 90 0       -  400000     -   - -
      -     -     -  1785981 R 10  88  1140e617c8  c00000     -   - -
      -     -     -  1818741 S  0  82  1f100070f1001bc40 8410400     -   - -
      -     -     -  1835013 R  8  60 0       -  400000     -   - -
      -     -     -  1871873 S  0  62  1f100070f1001c940 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              
    atcom/talkweb/ecm/prebill/dao/impl/PrebillInstanceDaoImpl.getPrebillInstanceEntityById(PrebillInstanceDaoImpl.java:207(CompiledCode))
    atcom/talkweb/ecm/prebill/service/impl/PrebillServiceImpl.getPrebillInstanceEntityById(PrebillServiceImpl.java:155(CompiledCode))   
    atcom/talkweb/ecm/prebill/action/PrebillIreportAction.exportExcelDataOfDiary(PrebillIreportAction.java:455(CompiledCode))  

第七步：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文件是无法定位的，方法二当做方法一的备用方法，当然方法比较直观，在实际工作中需要灵活运用即可。