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

原文链接： 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
版权声明：本文为博主原创文章，转载请附上博文链接！

简单的cpu飙高问题定位脚本相关推荐

简单的cpu飚高问题定位脚本
老司机在定位和解决问题时都有着自己的一套方法论,总不能老踩一些重复的坑是吧.老司机一般多少都遇到过服务器cpu飚高的问题,定位问题的方法网上文章多如牛毛,现这里再总结一下,对于混部多个Java应用的服 ...
线上CPU飙高诊断定位
1. 先准备一段java程序,后台运行 2. 使用 top命令查看cpu的进程使用情况在这里看到了一个进程占据了99.3%的cpu利用率,这显然是出现了cpu飙升的情况,这会到期系统其他进程得不到c ...
jvm 崩溃日志设置_记一次JVM疯狂GC导致CPU飙高的问题解决
背景线上web服务器不时的出现非常卡的情况,登录服务器top命令发现服务器CPU非常的高,重启tomcat之后CPU恢复正常,半天或者一天之后又会出现同样的问题.解决问题首先要找到问题的爆发点,对于 ...
面试官：线上服务CPU飙高怎么排查？
用jstack排查先执行top,找到CPU占用比较高的进程 jstack 进程id > show.txt 找到进程中CPU占用比较高的线程,线程id转为16进制到show.txt文件中根据线 ...
记一次jvm疯狂gc导致CPU飙高的问题解决
在环境上遇到tomcat频繁gc导致cpu load飙高的问题,本来想自己写一个文章的,看到这个偷懒转载一下. 线上web服务器不时的出现非常卡的情况,登录服务器top命令发现服务器CPU非常的高. ...
你要偷偷学会排查线上 CPU 飙高的问题，然后惊艳所有人！
作者 l Hollis 来源 l Hollis(ID:hollischuang) 前段时间我们新上了一个新的应用,因为流量一直不大,集群QPS大概只有5左右,写接口的rt在30ms左右. 因为最近接入 ...
JVM优化之系统CPU飙高和GC频繁
本文来说下JVM优化之系统CPU飙高和GC频繁文章目录概述 Full GC次数过多 CPU过高某个线程进入WAITING状态死锁本文小结概述处理过线上问题的同学基本上都会遇到系统突然运行 ...
java进程CPU飙高
早上某段时间突然看到看到一台生产机器上的CPU飙高 top 然后就请出了大神工具JVM 具体JVM的介绍看:http://www.cnblogs.com/smail-bao/p/6027756.htm ...
生产环境CPU飙高问题解决，记一次完整解决过程
一.发现问题前段时间我们新上了一个新的应用,因为流量一直不大,集群QPS大概只有5左右,写接口的rt在30ms左右. 因为最近接入了新的业务,业务方给出的数据是日常QPS可以达到2000,大促峰值Q ...

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

简单的cpu飙高问题定位脚本相关推荐

最新文章

热门文章