Details
On my ESX Server with Dell OpenManage installed, I notice regular spikes of very high CPU utilization.
Solution
The magnitude of the spike in CPU utilization is a metering artifact of the IPMI interface.
The IPMI system management driver may consume a lot of CPU, but it does this with low priority, so it should not block other CPU users. It uses much less CPU on a busy system. It basically soaks up what would otherwise be idle time.
During the high peak periods, the kipmi0 thread is attributed because it's always expecting data, and it's always ready to run. It can only read one char at a time, so when it's done it calls schedule() so any other process that's ready to run can go. Sleeping for a clock tick is way too long to wait, so it loops on polling the status register and calling schedule(). In this way, either another process is using the CPU or kipmi0 is, at all times. This persists until IPMI is no longer waiting for a response, at which time it goes into a more patient poll()ing cycle. Since none of the other processes are grabbing a lot of CPU time, kipmi0 is typically assigned the usage.
A possible workaround is to configure the IPMI driver to poll only on the clock tick. This causes the apparent CPU usage to essentially disappear, at the expense of dropping the performance of IPMI data acquisition by several times. To slow the IPMI sensor queries, pass the parameter si_force_kipmid=1 when loading the ipmi_si_drv module.
To do this:
Edit the file /etc/init.d/ipmi
Change the line:
modprobe $IPMI_SI_MODULE_NAME > /dev/null 2>&1
To:
modprobe $IPMI_SI_MODULE_NAME si_force_kipmid=1 > /dev/null 2>&1 # disable kipmi0
The change takes effect on the next system reboot.
Based on VMware KB 1004508
