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

群晖docker cpu利用率低 群晖cpu使用率高_java

方法一:过程+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文件后,我们可以看到线程状态如下:

群晖docker cpu利用率低 群晖cpu使用率高_分析工具_02

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


群晖docker cpu利用率低 群晖cpu使用率高_java_03

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