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