总结一次CPU占用1600%问题的定位过程

这篇文章主要讲解了“总结一次CPU占用1600%问题的定位过程”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“总结一次CPU占用1600%问题的定位过程”吧！

起因

1. 经过一次稍微大的改版后，系统上线，上线后测试没发现问题，第二天反馈系统卡顿，下线。

2. 检查系统问题 ,优化接口速度 上线，上线后发现没问题，第二天依旧出现卡顿。此时观察CPU占用1600%.此时想到的时先回滚。没有保留现场。

3. 测试环境测试，发现cpu空闲时占用100% 找到问题 修复。但是可以确定，这里100%不是引起1600%的原因。

4. 再次上线，人工实时监控cpu占用率。此时出现了1600%的情况。此时占用cpu 1600%的进程对应的线程如下.

6619 6625 等是占用最高的进程Id.

对JVM栈信息进行打印 并输出到文件。

6619转成16进制后为19db 根据进程号在栈文件中搜 如下图所示

最后发现占用cpu高的全部为gc进程 ，此时可以判定。有部分代码逻辑内存占用过高。或者出现内存泄漏。

寻找问题

此时已经连续三次上线失败，没办法在从线上测试。那么想的是在灰度环境模拟这个现象 然后dump堆信息 这样肯定可以找到原因。

1. 第一天 转移很少一部其他系统流量，以及很少一部分用户流量过去，没发现问题。

2. 第二天 其他系统请求的流量保持不变，增加更多的用户流量，没有复现问题。

3. 第三天 增加部分其他系统请求的流量，没有复现问题。

4. 第n天 增加其他系统请求的流量 内存调整小，没有复现问题。

5. 第n+1天 灰度环境服务与正式环境平分流量，继续增加用户量。没出现问题。

此时核心流程代码修改过的部分 已经检查了n遍 没发现问题。

那么 需要思考一下，为什么灰度环境没有问题。而线上有问题。他们的用户有什么不同？

此时发现灰度环境全是权限最低的用户，而管理员没有在灰度环境上工作，想到这里 问题已经离真相很近了。可以说已经定位到问题所在了，只需要验证一下自己的猜想。

其中有个功能，是查看自己所管理人的数据，这个功能因为不是核心功能 ，并且请求的量很小很小，起初并没有向这个方向考虑。
逻辑是 ： 查找自己下一级别，如果有数据，在继续查找，恰好 数据库有一条异常的数据 ，他的下一级就是自己！ 导致产生了死循环，导致内存里的数据越来越多。

并且 只有那一个异常用户才会引起这个问题！

又因为是IO密集的操作，所以 这个循环占用的cpu很低。在线程栈中并没有发现他。

解决问题

找到问题解决就是很容易的事情了，不再详细描述。

反思

第一次系统出现卡顿，正确的处理方式大概应该如下

1. 发现cpu占用高，查看该进程对应的线程在执行什么操作

2. 发现大量的线程在执行gc操作，此时应该dump堆信息

3. 使用jmap等工具查看哪些对象占用内存占用高

4. 找到对应代码 解决问题

这种bug不应该存在，即使存在了出现问题也不要太慌 应该快速的保留能保留下来的信息。

大的改动上线前需要灰度发布，少量用户先使用。

感谢各位的阅读，以上就是“总结一次CPU占用1600%问题的定位过程”的内容了，经过本文的学习后，相信大家对总结一次CPU占用1600%问题的定位过程这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！