search

BMC故障导致kipmi0极高的CPU使用

hashtag
快速起步

如果你没有时间看完这篇文章，这里有一个快速起步的三板斧：

  • BMC故障导致IPMI接口无响应，会导致大量ipmitool监控hang住占用系统资源（目前监控框架已经修改，超过10个ipmitool进程将不再发器新IMPI监控指令），此时top显示系统负载极高，同时没有实际CPU占用程序，也没有iowait，却有一个100%占用CPU的kipmi0进程。

  • 修复BMC的手段是reset cold，请依次通过如下方法尝试修复：

    • 在操作系统内执行 ipmitool mc reset cold - 有一定概率能冷重启BMC

    • 通过移除ipmi相关内核模块解决kipmi0占用CPU资源问题：rmmod ipmi_si - 这个步骤不解决BMC无响应故障，但通过关闭ipmi接口可以解决系统负载问题

    • 终极大招：通过OOB管理服务器向服务器管理IP发送指令ipmitool -I lanplus -H <oob_ip> -U <username> -P <passwd> mc reset cold冷重启BMC

如果你还有兴趣，请看以下排查故障的过程：

hashtag
故障现象

最近遇到用户反馈kvm虚拟机中运行的应用响应缓慢（RT较高），对物理服务器检查，意外发现系统有一个非常高的负载的kipmi0进程。这个kipmi0进程是和BMC通讯的，通常应该极少占用资源。

top - 20:05:20 up 87 days,  7:59,  2 users,  load average: 193.69, 113.92, 81.70
Tasks: 729 total,   3 running, 726 sleeping,   0 stopped,   0 zombie
%Cpu(s): 93.3 us,  3.7 sy,  0.0 ni,  3.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 19786745+total,  3874380 free, 19185401+used,  2139072 buff/cache
KiB Swap: 12582904 total, 12582904 free,        0 used.  5360364 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
16114 root      20   0 92.520g 0.088t   6588 S  3013 47.8  25928,15 qemu-kvm
10926 root      20   0 92.583g 0.088t   6264 S  3005 47.8  26079,01 qemu-kvm
11749 root      39  19       0      0      0 R 100.0  0.0  33718:35 kipmi0

上述故障的特征是：

  • 系统load负载极高，但是应用程序运行占用的CPU资源很低，并且没有iowait（表明没有磁盘故障）

  • 系统有一个kipmi0进程接近100%占用了一个CPU资源

检查可以看到这个系统中有大量的ipmitool进程，显示很多ipmi监控脚本都么有执行完一直卡在系统中，大量消耗系统资源。

选择检查其中一个ipmtool进程的stat，显示处于轮询等待中

杀掉所有ipmitool进程可以缓解负载问题

hashtag
故障排除笔记

hashtag
操作系统内mc reset cold

这个故障现象以前发现过，是因为带外oob控制器死机导致无法响应查询。彻底解决的方法是cold reset带外设备，如果cold reset无效则需要维修带外设备。

如果能够登录服务器，则可以在改服务器操作系统内部执行mc reset cold。如果幸运地冷重启BMC，则可以看到top 中的 ipmitool0 进程 占用的cpu资源迅速从 100% 降低到0。

如果操作系统内部执行ipmitool命令会没有响应。则可以尝试卸载ipmi内核模块或者通过带外重启MC

hashtag
卸载ipmi模块

首先可以尝试卸载ipmi内核模块

检查ipmi内核模块

可以看到操作系统使用了如下内核模块

卸载内核模块ipmi_devintf(针对IPMI驱动的用户端IOCTL接口，每个为这个设备打开文件将绑定到消息处理器message handler作为一个IPMI用户)

此时kipmi0负载没有降低

尝试卸载内核模块ipmi_si（不同系统接口的驱动）

GOOD，可以看到kipmi0进程的100%负载立即降低到0。

参考 Kipmi0 eating up to 99.8% cpu on centos 6.4arrow-up-right 的建议方法，采用卸载ipmi_si和ipmi_msghandler可以解决kimpi0负载高的问题。

注意：卸载内核模块要按照模块引用计数器来卸载，引用计数为0的模块先卸载，所以先卸载ipmi_devintf,ipmi_si和acpi_ipmi，然后再卸载ipmi_msghandler。

继续将所有ipmi模块都卸载掉

确定所有ipmi模块都卸载之后，尝试过sudo /etc/init.d/ipmi start，发现会导致modprobe ipmi_si进程D住：

说明IPMI驱动接口内核模块无法启动，检查堆栈可以看到sys_init_module内核函数没有返回

要重新卸载ipmi_si内核模块，首先要确保这个文件没有打开，否则会提示in use

检查打开到文件句柄

杀掉进程15528之后查看再查看内核模块

注意：这里虽然看上去ipmi_si模块已经加载到内核，实际上ipmi0设备文件初始化没有成功，导致/dev/ipmi0设备不存在，无法通过ipmitool进行操作，例如

实际可能硬件存在故障，无法初始化驱动

检查集群中其他服务器的/dev/ipmi0设备，可以看到

所以尝试在这台故障服务器上手工创建设备文件

尝试使用sh MAKEDEV ipmi0提示错误MAKEDEV: MAKEDEV: cannot execute binary file，没有明白^_^

不过，实践发现内核模块ipmi_si没有正确加载情况下，即使手工创建/dev/ipmi0设备文件也无法执行mc reset cold，报错依旧。

hashtag
终极大招：OOB带外mc reset cold

从带外oob管理机直接oob设备发reset指令。

如果电源状态能够检查到，就说明至少通过网络访问oob是正常的，此时可以尝试通过ipmitool的lanplus方式冷启动一下

前面手工mknod ipmi0 c 247 0创建的设备文件已定要先删除，否则即使mc reset cold之后再启动service ipmi start系统日志还会显示报错，并且导致modprobe ipmi_si进程D住：

实际修复是通过终极大招OOB带外mc reset cold来修复完成：

  • 操作系统内部由于BMC无响应，所以无法重新加载ipmi_si内核模块，所以也无法在操作系统内部ipmitool mc reset cold

  • 如果带外能够通过lanplus接口reset cold一次BMC，则会恢复操作系统内部和BMC的通讯，所以这个方法修复的可能性较高。

hashtag
参考

Previousipmi操作和对应的sel日志记录NextHP服务器frimware问题导致ACPI缓存大小相关报错

Last updated