1.现在已经证实这是rhels的一个bug，将这个bug进行较为深入的分析后，发现这个bug很有意思：
事情的来龙去脉估计是这样的：
先要从MCE说起。MCE（Machine Check Exception)是一类计算机硬件错误，它发生在当计算机的CPU侦测到硬件问题时。MicroSoft 的windows通常会以蓝屏来显示这类错误：
STOP: 0x0000009C (0x00000004, 0x00000000, 0xB2000000, 0x00020151) "MACHINE_CHECK_EXCEPTION
在Linux上，cpu通常会将这些信息写到kernel log中，有些时候如果这些硬件问题不能得到修复的话也会将信息写到控制台上（console screen）如：
CPU 0: Machine Check Exception: 0000000000000004 Bank 2: f200200000000863 Kernel panic: CPU context corrupt
以上显示的这类信息都是一些16进制的地址，并不能给我们直观的认识。怎样对这信息解码是一个很大的问题，当然我们可以去咨询CPU厂商，或是阅读他们的 文档。
在Linux下有一款软件mcelog（软件地址为/usr/sbin/mcelog，日志地址为/var/log/mcelog)是专门用来对以上的错 误代码进行解码的（decode）。
接下来就说到问题的正题上了。我们知道rhels也是有可能运行在Xen虚拟环境下的，即作为DomainU来运行，这时就不需要去运行mcelog了， 因为它本身就在虚拟的硬件环境上，出了问题也是软件虚拟的问题。从/etc/cron.hourly/mcelog.cron中可以看见系统开发者的意 图：
#!/bin/bash
if [ -e /proc/xen ] && [ `cat /sys/hypervisor/uuid` != "00000000-0000-0000-0000-000000000000" ]; then
# this is a PV Xen guest. Do not run mcelog.
exit 1;
else
/usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog
fi
系统开发者的意图是好的。但是，在全部默认安装rhels的时候，我们会将带有xen的kernel安装到机器上，而且此时的xend是不会自动启动的， 即后面的`cat /sys/hypervisor/uuid`会阻塞。又由于这段代码是写在/etc/cron.hourly中所以就会出现大量的`cat /sys/hypervisor/uuid`阻塞，而这时系统的负载（根据负载的定义）自然就上去了。
2.问题解决办法
看完上面的分析，就知道怎么解决了。你可以将上面的关于PV Guest的监测代码删掉（现在的系统就是这么干的）。或是添加更加严格的监测代码：
#!/bin/sh
xendstatus=`service xend status`
if [ "$xendstatus"="xend is running" ]; then
if [ -e /proc/xen ] && [ `cat /sys/hypervisor/uuid` != "00000000-0000-0000-0000-000000000000" ]; then
# this is a PV Xen guest. Do not run mcelog.
exit 1;
else
/usr/sbin/mcelog --ignorenodev --filter >> /var/log/mcelog
fi
else
exit 1;
fi
或是有这样的解决(基于半虚拟化的特点）：
if [ -e /proc/xen/capabilities ]; then
#xen
grep control_d /proc/xen/capabilities > & /dev/null
if [$? -ne 0 ]; then
#domU -- do not run on xen PV guest
exit 1
fi
fi
或者你不用带用Xen的kernel来启动系统。
方法很多，任由你选吧。
参考目录：
http://en.wikipedia.org/wiki/Machine_Check_Exceptionhttps://bugzilla.redhat.com/show_bug.cgi?id=225203