事故背景
昨天晚上半夜3：26分被电话铃声吵醒了，看到一个未接电话，然后看到微信里面同事拉了群，看到是我负责的一个服务分布式文件存储系统报警了， 报警信息是部署该服务的所有机器同时出现了load average,并且运维同事已经尝试重启应用来恢复负载过高问题，依然无效，重启应用之后服务器负载又马上飙山来。
处理过程
由于我刚刚入职该公司，接手这个文件存储系统不到2个礼拜，而之前开发的人都离职了。这个系统非常重要，整个公司的所有的涉及到文件存储的应用都是接入该服务，一旦出现故障将会影响全站的服务，因此，必须在天亮前回复服务器压力，避免影响白天应用对外的服务。这个时候我感到一股前所未有的压力，我一下清醒了，考虑到在家里没有生产权限，只能和运维配置一起排查问题，我按时间顺序大概做了这么几件事：
- 上监控系统查看是否又报错日志，排查系统报错导致的负载；
- 找运维查看jvm的gc日志，排查是否存在异常的gc；
- 找运维执行 jstack -l pid 查看应用是否存在异常的线程堆栈信息。
- 运维给出了top截图，看当前服务器资源使用和进程的情况
1~3 都正常，top命令看到 load average w1 w5 w15 都达到10以上，cpu只用了不到1%，看上去是一个cpu低，负载高的问题，因为程序既没有出错，运行状态看上去也正常感觉负载高可能不是应用本身造成。
- 让运维看下磁盘容量：由于该系统是文件存储系统，因此我们怀疑下是否由于磁盘满了导致了负载过高呢？
在运维执行 df -h 命令时一直卡住无法出结果，感觉可能和磁盘有关系，部署文件存储系统的服务器都挂载了NAS存储设备，于是开始联系负责NAS服务的运维，发现有个NAS服务挂掉了，重启NAS服务之后，重新挂载NAS盘，系统开始恢复。
分析总结
本次问题的根本原因是NAS所在的宿主物理机发现宕机，导致虚拟机的NAS服务重启，重启后该应用（nfs）没有设置开机自启动，进而导致了文件存储系统所在的机器连接挂载的存储设备，因此文件存储服务无法读写该设备，造成了IO等待的过高的负载。
最后大家可以看下该文章的分析，我们的情况在他的分析之中。cpu使用率低负载高，原因分析
网友评论