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

我不是女神ヾ 2022-03-02 09:48 251阅读 0赞

原文链接： [https://blog.csdn.net/manzhizhen/article/details/79333676][https_blog.csdn.net_manzhizhen_article_details_79333676]

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

找到cpu占比高的Java进程ID，通过这一步就知道是哪个Java应用出了问题。  
然后再找到该Java进程中哪些线程占用cpu时间比较高，有时候步骤2和步骤1可以合为一个步骤。  
jstack -l 该Java进程到某个文件(比如/tmp/jstack.dump)。  
再将步骤2得到的线程ID由10进制转换成16进制，去jstack.dump文件中看这些线程到底是执行了哪些Java代码，从而可以找出问题。  
先来看看步骤1，定位cpu占比高的Java进程比较简单，可以直接通过top命令或ps命令，但由于top命令比较简单，不像ps命令有过多的参数，所以大多数会优先使用top命令。找到出问题的Java进程后，就知道是哪个应用出问题了，这时候该应用的Owner就应该通知到位了。

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

top命令 + （shift+H）实时显示线程用肉眼看！  
top -Hp $pid 实时用肉眼来看！  
ps -mp $pid -o THREAD,tid,time 直接看线程快照结果。  
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飙高问题，先多次执行该脚本以便留下“犯罪”现场，然后再重启或回滚服务，后面再去分析该脚本生成的文件来定位问题。

本文很短，也没有阐述高深的技术知识，但想和各位分享一句从老大那听来的一句话：将小事做到极致，就是创新。工作如此，人生也如此。  
\---------------------   
作者：大步流星Java   
来源：CSDN   
原文：https://blog.csdn.net/manzhizhen/article/details/79333676   
版权声明：本文为博主原创文章，转载请附上博文链接！

[https_blog.csdn.net_manzhizhen_article_details_79333676]: https://blog.csdn.net/manzhizhen/article/details/79333676