记一次 [TOP、PS等多命令不可用 服务器load average过高 服务器频繁宕机 无异常宕机]的经历

背景

1. 服务器及业务应用稳定运行一年以上，突然某一天宕机；
2. 联系机房重启后，系统及业务日志没发现明显异常，甚至无错误；
3. 同时重启多个业务应用后，不到一会又宕机；
4. 逐个重启业务应用，正常运行了几天后又一次宕机；
5. 与机房运维人员沟通，那边分析日志后说硬件没问题；

宕机前现象

1. 重启后服务器一切正常，空运行几个小时都没问题；
2. 一些小业务量（甚至没有业务量）的程序（以下简称为A程序）启起来后，几个小时也都没问题；
3. 当启动集群该节点的程序后（以下简称为B程序，该程序启动后会扫描磁盘数据，并重建索引，还会从其他节点复制数据），几分钟乃至十分钟之内正常，十分钟之后top、ps等命令都僵死，乃至最后reboot命令都卡死，直至宕机ping不通。
4. 某次重启后，观察到B程序CPU使用率不高，单进程从没超过100%，CPU总体使用率不超过10%；服务器内存有一半以上未使用。倒是load average指标在B程序启动后，一段时间内正常，之后短时间内就飙升至30+ 30+ 30+；此时TOP等命令僵死；主机还能正常登录，ls命令也能正常输出；再之后就宕机了

问题排查

1. 系统日志/var/log/message里没发现什么异常
2. last命令查看系统重启时间什么的，也无异常
3. lastlog命令查看登录日志，也无异常
4. 查看业务日志也无异常

到这里能断定是硬件问题了。。。但是！！！机房运维人员说，分析日志无异常，不是硬件问题！说应该还是业务应用的问题。此时懵了，最近没有更新上线，之前也稳定运行了许久的应用，会有什么问题呢？日志也没错误输出啊？负载也不高啊（程序启动到一半就挂了，根本没启起来）？由于是JAVA程序，中间还换过JDK小版本，但是问题依旧。

后来考虑可能是重启多次，本机磁盘上可能产生了脏数据导致程序异常，所以准备把数据备份一下，然后作为一个无数据的节点加入集群后，从其他节点同步全部数据。然后就执行mv命令把数据（大概200G）复制到另外一个挂载盘，再然后。。。在mv的过程中，机器又一次load average飙升，最后宕了。此时我算是搞明白了，根本不是业务应用的问题，肯定是硬件或系统的问题！因为我应用程序根本还没启动啊。

再之后上网搜资料，发现了这么一篇文章一次服务器宕机分析，恰巧我们硬盘也是做了raid，跟这个现象很像（只不过原文章现象说的不太清楚，我这里再发文章描述一下，方便大家对比判断）。第二天早上把“执行mv命令依然宕机的现象”跟机房的人说明，并推了这篇文章。机房跟厂商沟通后，死马当活马医，换RAID卡BBU电池！当天下午换上之后，系统启起来，业务跑起来，一切正常！！！

根本原因

还是硬件问题：Raid卡BBU模块电池问题。不过不清楚为什么没有错误日志以及硬件厂商也没发现问题。

尴尬的后续----
可能不是该问题。只稳定运行了几天，又复现了这个问题。尚未解决，待更新

----20210720
今天看到又小伙伴发评论说好文章，受之有愧。也顺便更新下这个问题后续。

后续就是跟机房的人查了好久，也重装过操作系统。执行mv命令一段时间后，仍然load avg飙高，最终宕机。后来多次测试发现，部分数据怎么mv都没有任何问题，部分数据一mv就异常。由于数据有副本备份，直接把这些“异常的数据”删除，后来再把服务启动，至今也没再宕机了。 后来我也没深入查资料，我自己怀疑是kafka为了高吞吐，有些顺序写磁盘等高级操作。可能某天由于某些原因触发了某个BUG，导致落盘的数据存在问题，影响到操作系统读写。