一次运维事故调查报告--cpu负载过高

题记：只要时间足够，在开发期间偷得懒，运维期间总会在某个恰当的时机有大的坑等着，不是坑到自己就是坑到后来人 ；

九月份的某个深夜，被电话吵醒，运维说线上某个版本的两个服务器由于系统资源耗尽（主要是系统CPU负载过高），宕机了，导致操作系统无法执行正常指令；我顿时激灵了一下，我嚓，我们是java开发的系统，即便有个内存泄露也不会这么严重到宕机；脑海中顿时蹦出以前处理的各种宕机情况，先不考虑内存泄露，肯定是出现类似死循环的效果的代码了。由于凌晨这个点，找到相关人来进行问题修复发布更新已经不可能，为了尽快恢复服务，让运维人员赶紧备份现状，开启进程；

第二天早上，上班期间排查问题，未发现项目日志里面有异常情况。看了一下机器的性能，也非常强大，不至于出现系统负载问题，何况国内版本跟这个版本逻辑上一样，唯一区别的就是运维的环境区别；询问了一下运维同事，了解到国内版本其实国内机器硬件配置还不如这个环境，并且docker承载量更多，那显然不是硬件问题了；宕机的两个服务器都属于一台物理机的两个docker虚机，通过top观察发现cpu负载忽高忽低，最高可以达到900%；问题应该是某段代码耗时比较大，长期占有CPU这样的宝贵资源。知道大概方向，便开始查找原因，分析几个jstack日志，由于CPU的高低并不是必然的，“毫无规律”可言，感觉已经完全看不出问题了；后来使用top P指令查看了占用比较高的几个进程，确实是几个JAVA进程占用