简单的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后的文件即可完成问题定位！

 

<!--StartFragment--> <!--EndFragment-->

先来看看使用该脚本生成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飚高问题，先多次执行该脚本以便留下“犯罪”现场，然后再重启或回滚服务，后面再去分析该脚本生成的文件来定位问题。

 

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

<!--StartFragment--> <!--EndFragment--> 

评论

4 楼 manzhizhen 2018-03-02  

pan19849529 写道

'/javacpu.sh: line 10: syntax error near unexpected token `
'/javacpu.sh: line 10: `        fi 

这个只能在你电脑具体调试了，我试了几个我同事的电脑，没问题了，你找你同事帮你调试下吧。

3 楼 pan19849529 2018-02-28  

'/javacpu.sh: line 10: syntax error near unexpected token `
'/javacpu.sh: line 10: `        fi 

2 楼 manzhizhen 2018-02-28  

pan19849529 写道

shell 脚本10行报语法错误

能发出来吗？我这边试了是没问题的。。。

1 楼 pan19849529 2018-02-27  

shell 脚本10行报语法错误