CPU扛不住了

前言

这是一篇根据生活编撰的一个小故事，讲述了一个比较少见的服务器问题——CPU利用率过高。文中包含了从CPU过高告警，到一步步定位到导致CPU过高的代码的追溯过程。

前面是小故事，算是场景引入，如无兴趣可绕过从后记部分开始。郑重声明：故事很小，如有雷同，纯属虚构。

正文

“快看看，CPU利用率爆红了，看着要扛不住了！”小P打电话吼道，小P是服务器的监控。

“什么鬼？”,正准备睡觉的小码爬了起来，小码是系统的开发者。

“我一个没多少计算的应用服务怎么就扛不住了，一定是其他服务导致的！”小码嘀咕道。

开机！

登录VPN！

打开finalShell，ssh服务器一气呵成。

看着自己娴熟的操作，小码的嘴角漏出了一丝丝骄傲。

top # Linux系统下，可以查询当前正在运行任务，包含CPU利用率、内存等信息，类似于Windows任务管理器

啪，回车的声音依然清脆，仿佛在迎合着小码的自信。

“我丢@@@”CPU使用率排行第一个是一个Java应用，进程ID 136018，“不会吧...”，嘴角微微抖了一下。

ps -aux | grep xxx-manager.jar #说明：查询服务的进程，xxx-manager.jar是服务包名，端口也可

果然，136018！136018！136018... 通过多次仔细比对CPU利用率top1的进程号和自己服务的进程号，确定是小码负责的服务！小码后背一下凉了半截。

“赶快排查排查，趁服务还没宕机”

top -H -p 136018 #说明：-H开启线程模式，-p指定服务进程号

然后找到疯狂占用CPU的线程ID: 136086

printf %x 136086 #说明：此命令是将10进制转换为16进制，因为jstack中线程ID是16进制。136086转换后是0x21396

jcmd Thread.print > jstack.out # 说明：jcmd是jdk自带的分析工具，此命令会将当前jvm栈信息输出到jstack.out文件中。

最后，vim进入jstack.out文件，搜索0x21396，找到线程栈信息，就看到了业务代码。

业务伪代码

for(int i = 0; i < 65535, i++){

methodB(i)

}

void methodB(int i){

for(int j = 0 ; j < 10086; j++){

...

"这..."，循环调用了一个方法methodB，该方法里面还有个循环，类似于循环嵌套循环。外层遍历次数6万+，嵌套循环次数1万+，MD这一个来回就是6亿多次。再看看接口调用方，是页面初始化加载...

“我......”，小码看着祖传代码陷入沉思，“难怪号称宇宙第一块的CPU都扛不住了”。

正在思考解决办法的时候...，“醒醒...小码！你电话响了！”，同事叫醒了呼呼大睡的小码。

看着午睡宝上面一滩口水，小码心里庆幸到：“哦，原来是一场梦啊！”。

“电话！小码！你的电话！！”

来不及去回味残余的一丝丝侥幸，小码赶快看了看手机：【13个未接来电，来自客户老总】。

“我丢@@@”，不会真扛不住了吧...

后记

本文通过一个小故事，讲述了一个比较少见的问题-CPU利用率过高的问题，包含了发现CPU过高告警，到找到导致CPU过高的代码的追溯过程。

定位步骤：

1.首先查看CPU高占用率的进程号，根据进程号查询CPU高占用率的线程ID，使用top命令。

2.快照当前服务端栈信息，线程ID转为16进制在栈信息文件里查找对应线程栈，即可找到导致CPU疯狂飙升的代码了。

3.然后根据需要，进行业务或者算法上面的调整优化。

最后

• Linux命令：top、ps、printf和vim，通过man 命令可以查看文档，例如：man top
• jcmd工具官方文档： https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr006.html#BABEHABG
• 感悟：对于循环嵌套，注意循环集合的大小，适当评估计算量，敬畏代码。