发现kipmi0消耗单核资源

今天在处理一个报警的时候,意外发现集群中有一个服务器节点有一个 kipmi0 进程占用了单个cpu的100%资源

top - 05:33:19 up 38 days,  5:30,  1 user,  load average: 1.02, 1.10, 1.22
Tasks: 528 total,   2 running, 526 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0%us,  4.8%sy,  0.0%ni, 94.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  99036100k total, 97638304k used,  1397796k free,   215656k buffers
Swap:  1999864k total,   141984k used,  1857880k free, 91091652k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  338 root      39  19     0    0    0 R 100.0  0.0  14902:34 kipmi0
 4468 root      20   0 1739m  66m 2660 S 36.0  0.1  28670:33 glusterfsd
 7920 root      20   0 15404 1600  948 R  1.9  0.0   0:00.06 top
    1 root      20   0 19360 1160  964 S  0.0  0.0   0:02.33 init

查看 /var/log/messages 日志并没有发现硬件异常。

kipmi0进程

kimpi0 进程是用于监控硬件感应器,通过Linux驱动来执行硬件感应器监控。

检查

由于集群中部分节点出现上述 kimpi0 进程占用一个cpu内核的情况,检查 ipmi 相关进程可以看到:

ps -ef | grep ipmi | grep -v grep

导致 cpu 资源消耗出现问题的节点都执行了 ipmitool 命令,并且命令执行已经超过10天:

root       380     1  0 Aug30 ?        00:00:00 /usr/bin/sudo /usr/bin/ipmitool mc info
root       382   380  0 Aug30 ?        00:00:00 /usr/bin/ipmitool mc info
root       404     1  0 Aug30 ?        00:00:00 /usr/bin/sudo /usr/bin/ipmitool sel elist
root       405   404  0 Aug30 ?        00:00:00 /usr/bin/ipmitool sel elist

以上指令是监控系统搜集服务器硬件信息和日志的脚本中的命令,其中 ipmitool 参数含义如下:

mc Management Controller status and global enables

sel Print System Event Log (SEL)

不过,杀死上述进程并没有使得 kipmi0 消耗的cpu资源下降下来。

在正常节点上执行上述脚本,例如 /usr/bin/ipmitool sel elist 可以正常输出硬件系统事件日志,但是异常节点会卡住没有输出信息。

尝试重启带外管理控制器(Management Controller)

ipmitool mc reset cold

同样出现卡住现象,没有能够reset成功。

检查当前Linux加载的ipmi模块:

lsmod | grep ipmi

显示操作系统只加载了 ipmi_devintf 模块 (Linux device interface for the IPMI message handler)

但是尝试卸载 ipmi_devintf 模块失败:

#rmmod ipmi_devintf
ERROR: Module ipmi_devintf is in use

此外, kipmi0 进程也无法杀死,无法降低cpu消耗

服务器集群 dmdecode 输出信息里面厂商的信息是 Inspur (原来是国产品牌”浪潮”) 。

ipmi相关系统服务脚本

/etc/init.d 目录下有两个和ipmi有关的服务脚本:

  • ipmi - 加载ipmi的内核模块,默认启动
  • ipmievd - 将ipmi事件发送给syslog服务,默认这个服务不启动

上述两个服务脚本启动的相关参数见 /etc/sysconfig 目录下的配置文件 ipmiipmievd ,其中

  • /etc/sysconfig/ipmi 配置中:

    IPMI_SI=yes #激活标准硬件接口(KCS, BT, SMIC)
    DEV_IPMI=yes #激活 /dev/ipmi0 接口,用于 ipmitool, ipmicmd

  • /etc/sysconfig/ipmievd 配置:

    IPMIEVD_OPTIONS=”sel pidfile=/var/run/ipmievd.pid”

启动 /etc/init.d/ipmievd start 可以看到系统 /var/log/messages 中输出了硬件平台日志。

处理kipmi0问题

kimpi0 进程在IPMI (Intelligent Platform Management Interface, 智能平台管理接口) 设备,例如BMC(Baseboard Management Controller,主板管理控制器)或IMM(集成管理控制器)繁忙时或者没有响应时会消耗cpu资源到100%(单核)。 无需修复,因为这个CPU资源占用不影响系统的实际响应。( Kipmi0 May Show Increased CPU Utilization on Linux )

修复的方法是,如果使用IPMI设备,则 reset BMC或者重启系统。如果不使用IPMI设备,则使用命令 service ipmi stop 停止IPMI服务。

  • 解决记录:

我尝试了ssh登录操作系统执行 ipmitool mc reset cold 但是没有响应返回

然后尝试从网络通过 -I lanplus 方式访问,意外发现能够查询出主机电源状态:

ipmitool -C 3 -I lanplus -H 带外管理IP -U 登录名 -P 登录密码 power status

显示输出: Chassis Power is on

这样,我感觉从网络访问,仍然存在操作的可能。所以通过网络向控制器发出 mc reset cold 指令:

ipmitool -C 3 -I lanplus -H 带外管理IP -U 登录名 -P 登录密码 mc reset cold

提示 Sent cold reset command to MC

又尝试连接带外终端:

ipmitool -C 3 -I lanplus -H 带外管理IP -U 登录名 -P 登录密码 sol activate

仍然返回失败信息:

Error: Unable to establish IPMI v2 / RMCP+ session

不过,后来发现,实际上是BMC重启导致的连接失败。

意外发现,操作系统 top 显示的 kipmi0 已经不再占用CPU资源了。

kipmi详细的说明

kipmi导致的CPU使用增长是很常见的。这个硬件设备接口不是中断设备,所以驱动必须轮询设备的状态和消息。这个轮询显示成一个繁忙的CPU。kipmi内核线程的优先级非常低,所以不会影响系统中的其他进程。甚至当轮询进入死循环(通常是它认为BMC有活跃事件需要它处理),它仍然会在任何进程需要CPU资源时放弃占用资源。

CPU通常视 kipmi0 内核线程为IDLE时间。kipmi0在没有其他任务运行时运行,并且是系统最低优先级的进程。

可以通过以下方法使得 kipmi0 只使用 10% 的CPU: ( kipmi0 problem )

echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us

我验证了一下,这个命令确实可以限制 kipmi0 只使用 10% 的CPU资源。