文章目录
- 背景
- 一、告警分析
- 二、原因分析
- 1.找到java进程
- 2.进入 Arthas
- 3. 使用 Arthas 找到CPU占用最高的线程
- 4.定位原因
- 5.解决方案
- 总结
背景
某天下午频繁收到预发环境应用CPU告警；预发环境一般是项目、日常等即将上线时做最后回归时使用。出现CPU告警大概率是有新代码出现性能问题，一定要及时排查定位出来，绝对不能把问题带到线上；
一、告警分析
容器平均CPU使用率超过80%，告警比较频繁，平均每分钟都会产生一次告警；（告警信息如下图）
线上与预发环境CPU使用情况对比分析：告警主要发生在预发环境、线上CPU使用率正常；
二、原因分析
1.找到java进程
使用top命令，找到java进程的PID
2.进入 Arthas
在服务器上打开并进入 Arthas（安装入门见 Arthas 用户文档），如果服务器上有多个java进程，选择需要排查问题的 PID 进入：
3. 使用 Arthas 找到CPU占用最高的线程
方法1、输入 thread -n 3 会列举出当前三个占用CPU最高的线程，根据图中可以定位到具体的业务代码行数
方法2：使用 dashboard 查看java应用运行情况
可以看到占用CPU较多的线程都是：ConsumerImplV2-ClientBusiness-*****score_b，继续深入排查，找到其中一个线程，观察线程运行情况，执行命令：thread 1070 查看结果：
at com.xxx.xxx.xxx.biz.service.xxx.XLock.unlock(XLock.java:166)
at com.xxx.xxx.xxx.biz.service.xxx.XLock.executeWithLock(XLock.java:106)
at com.xxx.xxx.xxx.biz.service.statistics.impl.ScoreDataChangeInnerServiceImpl.reCount(ScoreDataChangeInnerServiceImpl.java:60)
at com.xxx.xxx.xxx.biz.service.statistics.impl.ScoreDataChangeInnerServiceImpl.reCountBatchLimit(ScoreDataChangeInnerServiceImpl.java:78)
at com.xxx.xxx.xxx.biz.service.statistics.impl.ScoreDataChangeInnerServiceImpl$$FastClassBySpringCGLIB$$c86131bb.invoke(<generated>)这里已经基本确认问题代码位置了，接下来继续分析代码；
4.定位原因
通过 ScoreDataChangeInnerServiceImpl 类中的相关日志，定位到某个正式商家在预发环境存在大量数据变更，产生大量数据变更消息消息，而预发是单机部署，一直在消费消息占用CPU较高；
因为正式商家的流量不会到预发环境，所以这里基本可以确定是某位同学在预发环境刷数据导致的，而并不是文章前面判断的“问题代码”导致；
5.解决方案
1、找到相关同学，同步不要再预发环境刷数据，因为预发环境部署的代码也算是上线前的测试代码，没有最终测试验收完成可能存在隐藏的bug。如果刷数据触发了bug，那么可能引起生产环境数据错乱，问题就更大了。
2、所以先将消息暂停消费（临时方案，此文重点分享服务器 CPU 飙高的排查分析过程，最终解决方案这里不细讲）， 由于需要保证商家店铺统计数据的准确性，所以消息不能丢弃。
消息暂停消费后，观察预发环境 CPU 使用情况：
总结
1、人是活的，要学会灵活使用方法，当工作经验丰富了，凭借经验对问题定位分析能够剩下不少时间；
2、敬畏线上，当预发环境出现问题就已经在警告我们线上可能也会出现问题，一定要及时介入排查；
3、海因里希法则：在机械生产过程中，每发生330起意外事件，有300件未产生人员伤害，29件造成人员轻伤，1件导致重伤或死亡；对应到我们软件开发中也适用，每 300 次轻微问题（例如：告警、ERROR日志等）会有29次线上问题产生（例如：线上bug、商家反馈等）1次故障产生；所以不要轻视每一次问题，你不解决问题，你就会成为问题；
