CPU100%问题快速定位思路

在我日常运维工作中，无论自己 或同事、朋友总会问我，服务器CPU使用率100%，卡死了，这样的话，那今天咱们就一起模拟故障，进行细致的分析，首先介绍下，CPU出现问题的几种原因：
博主最新文章地址： https://www.dgstack.cn/archives/178.html

一、CPU 100%问题定位

1、功能问题，通过日志，单步调试相对比较好定位。

2、性能问题，例如线上服务器CPU100%，如何找到相关服务，如何定位问题代码，更考验技术人的功底。

2018-6-4 今日在公司进行一次线上服务CPU问题排查实战演练，公司全体同事反馈有收获，特将故障演练报告分享出来，希望对大家也有帮助。

二、故障演练题目

某服务器上部署了若干tomcat实例，即若干垂直切分的Java站点服务，以及若干Java微服务，运维突然收到CPU异常告警。

问：如何定位是哪个服务进程导致CPU过载？
        哪个线程导致CPU过载？
        哪段代码导致CPU过载？

第一步 最消耗CPU的进程

工具 ： top或者 htop（高级）
方法：top -c 显示进程运行详细列表
键入 P （大写P），按照cpu进行排序

如上图，最耗CPU的进程PID为1865

步骤二：找到最耗CPU的线程

工具：top
方法：
top -Hp 1865 ，显示一个进程的线程运行信息列表
键入P (大写p)，线程按照CPU使用率排序

如上图，进程1865内，最耗CPU的线程PID为2747

步骤三：将线程PID转化为16进制

工具：printf
方法：printf “%x\n” 2747
图示：

如上图，2747对应的16进制是abbn，当然，这一步可以用计算器。

注意：之所以要转化为16进制，是因为堆栈里，线程id是用16进制表示的。

步骤四：查看堆栈，找到线程在干嘛

工具：pstack/jstack/grep

`方法：jstack 10765 | grep ‘0x2a34’ -C5 --color`

关于命令解析：

是线程堆栈值，命令在解释下：jstack pid命令 是查看当前运行程序进程的堆栈状态，通过将该pid转成16进制的值，在thread dump【这个是工具通过状态反馈问题点】中每个线程都有一个nid，找到对应的nid即可；隔段时间再执行一次stack命令获取thread dump，区分两份dump是否有差别，在nid=0x2a34的线程调用栈中，有多次调用现象就说明该地方可能代码有问题了。