简单的cpu飙高问题定位脚本

老司机在定位和解决问题时都有着自己的一套方法论,总不能老踩一些重复的坑是吧。老司机一般多少都遇到过服务器cpu飙高的问题,定位问题的方法网上文章多如牛毛,现这里再总结一下,对于混部多个Java应用的服务器,我们一般会通过如下步骤来定位该问题:

  1. 找到cpu占比高的Java进程ID,通过这一步就知道是哪个Java应用出了问题。
  2. 然后再找到该Java进程中哪些线程占用cpu时间比较高,有时候步骤2和步骤1可以合为一个步骤。
  3. jstack -l 该Java进程到某个文件(比如/tmp/jstack.dump)。
  4. 再将步骤2得到的线程ID由10进制转换成16进制,去jstack.dump文件中看这些线程到底是执行了哪些Java代码,从而可以找出问题。

先来看看步骤1,定位cpu占比高的Java进程比较简单,可以直接通过top命令或ps命令,但由于top命令比较简单,不像ps命令有过多的参数,所以大多数会优先使用top命令。找到出问题的Java进程后,就知道是哪个应用出问题了,这时候该应用的Owner就应该通知到位了。


步骤2是进一步定位到出问题的线程,常用的有如下几个方法:

  1. top命令 + (shift+H)实时显示线程用肉眼看!
  2. top -Hp $pid 实时用肉眼来看!
  3. ps -mp $pid -o THREAD,tid,time 直接看线程快照结果。
  4. ps H -eo user,pid,tid,%cpu --sort=-%cpu | grep $pid 直接看线程快照结果。

有时候为了简单,可以直接定位到出问题的线程,这是习惯问题,这里不做过多讨论。

不管怎样,都逃不过步骤3,即jstack进程到一个临时文件。

步骤4主要是分析问题了,有个稍微“恶心”的是jstack文件中的线程ID用的是16进制,所以我们得把步骤2得来的线程ID转一下。

由于上面4个步骤说长不长,说短也不短,特别是在定位线上问题时心里难免紧张,命令用的不熟的话,容易造成定位问题时间过长。

于是网上老司机就将如上4个步骤合成在一个脚本中,希望通过一个脚本就搞定,作者在网上也找了一些,有的写的很简单,但就是执行起来报错;有的写的很专业,功能齐全,文档也写的比较好,但过于复杂,修改起来难度高,不太敢在线上环境使用。

于是作者又花了点时间重复造了一个轮子,写了一个只有35行的Shell脚本,并"厚颜无耻"的写成了本篇博文,作者的思路其实很简单,将前3个步骤的结果直接写入jstack后的文件中,一个jstack后的文件即可完成问题定位!

先来看看使用该脚本生成dump文件内容:


有了上图的文件,就可以直接在文件中找cpu占比为94.3的0x65c6等线程的对于代码了!是不是很方便?为了方便多次采样,该脚本生成的文件名为pid-$pid-时间.jstack默认放在/tmp目录下,比如如果是ID为12345的Java进程的cpu占比最高,那么通过该脚本生成的文件有可能是/tmp/pid-12345-20180217T22:51:03.jstack

因为脚本做的事情不多,也很简单,只有35行,你看到哪里不爽,可以直接修改,下面直接附上该shell脚本代码:

#!/bin/bash

# 入参只有一个,即目标java的pid,如果没有,则默认找cpu最高的java进程
if [ -z "$1" ]; then
        ### 1.先找到消耗cpu最高的Java进程 ###
        pid=`ps -eo pid,%cpu,cmd --sort=-%cpu | grep java | grep -v grep | head -1 | awk 'END{print $1}' `
        if [ "$pid" =  ""  ]; then
                echo "无Java进程,退出。"
                exit
        fi
else
        pid=$1
fi

### 2.生成dump后的文件名 ###
curTime=$(date +%Y%m%dT%H:%M:%S)
# jstack后的文件会加上时间,便于对一个进程dump多次
dumpFilePath="/tmp/pid-$pid-$curTime.jstack"
echo -e "cpu最高的java进程: "`jps | grep $pid`"\n" > $dumpFilePath

### 3.取到该进程的所有线程及其cpu(只显示cpu大于0.0的线程) ###
echo -e "进程内线程cpu占比如下(不显示cpu占比为0的线程):\n" >> $dumpFilePath
ps H -eo pid,tid,%cpu --sort=-%cpu | grep $pid | awk '$3 > 0.0 {totalCpu+=$3; printf("nid=0x%x, cpu=%s\n", $2, $3) >> "'$dumpFilePath'"} 
END{printf("cpu总占比:%s\n\n", totalCpu) >> "'$dumpFilePath'"}'

### 4.dump该进程 ###
echo -e "如下是原生jstack后的结果:\n" >> $dumpFilePath
jstack -l $pid >> $dumpFilePath

echo "dump成功,请前往查看(文件名包含时间,为了采集更准确,可以多执行几次该命令):" $dumpFilePath

exit

记住,执行该脚本你得拥有使用jps、jstack等命令的权限。

使用方法(假设将上述脚本保存为javacpu.sh文件)

方法1:直接让脚本来查找cpu占比最高Java进程并在/tmp目录下生成dump文件,直接sh ./javacpu.sh即可。

方法2:直接使用该脚本在/tmp目录下形成某个Java进程(比如ID为123456)的dump文件,可以 sh ./javacpu.sh 123456

先解决问题再去定位问题,这是线上事故处理的第一原则,如果遇到线上cpu飙高问题,先多次执行该脚本以便留下“犯罪”现场,然后再重启或回滚服务,后面再去分析该脚本生成的文件来定位问题。


本文很短,也没有阐述高深的技术知识,但想和各位分享一句从老大那听来的一句话:将小事做到极致,就是创新。工作如此,人生也如此。


猜你喜欢

转载自blog.csdn.net/manzhizhen/article/details/79333676