Linux系统/sys/hypervisor/uuid阻塞，导致数据库进程异常停止的问题

数据库远程登录失败，检查服务器数据库进程发现数据库进程掉了，查看数据库日志发现如下报错：
Thu Nov 25 10:32:54 2010
Memory Notification: Library Cache Object loaded into SGA
Heap size 3567K exceeds notification threshold (2048K)
Details in trace file /opt/app/oracle/admin/METARDB/udump/metardb_ora_4344.trc
KGL object name :XDB.XDA8XlWX/h+P3gQFeMmGQWfg==
Thu Nov 25 10:36:47 2010
Errors in file /opt/app/oracle/admin/METARDB/bdump/metardb_dbw0_4206.trc:
ORA-01116: error in opening database file
Thu Nov 25 10:36:47 2010
Errors in file /opt/app/oracle/admin/METARDB/bdump/metardb_psp0_4202.trc:
ORA-01116: error in opening database file
重启数据库发生如下报错：
SQL> startup
ORACLE instance started.
Total System Global Area 9948889088 bytes
Fixed Size                  2037088 bytes
Variable Size            2617248416 bytes
Database Buffers         7314866176 bytes
Redo Buffers               14737408 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
查看数据库日志，报错如下：
Thu Nov 25 10:49:27 2010
Errors in file /opt/app/oracle/admin/METARDB/bdump/metardb_p009_5521.trc:
ORA-01110: data file 3: '/opt/app/oracle/oradata/METARDB/sysaux01.dbf'
ORA-01116: error in opening database file 3
ORA-01110: data file 3: '/opt/app/oracle/oradata/METARDB/sysaux01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 23: Too many open files in system
Additional information: 3
Thu Nov 25 10:49:27 2010
Errors in file /opt/app/oracle/admin/METARDB/bdump/metardb_p009_5521.trc:
ORA-01110: data file 4: '/opt/app/oracle/oradata/METARDB/users01.dbf'
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/opt/app/oracle/oradata/METARDB/users01.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 23: Too many open files in system
Additional information: 3
……
多个数据文件有相同报错，最后提示各进程启动失败。
由于报错中有“Too many open files in system”，检查系统内核配置：
# cat /proc/sys/fs/file-max
65536
最大打开文件数65536个，分析为系统打开文件数超过最大值，检查系统进程：
# ps -ef
发现进程中有大量如下进程：
root       450   448  0 Oct05 ?        00:00:00 cat /sys/hypervisor/uuid
root       482  5278  0 Nov17 ?        00:00:00 crond
root       484   482  0 Nov17 ?        00:00:00 /bin/bash /usr/bin/run-parts /etc/cron.hourly
root       485   484  0 Nov17 ?        00:00:00 /bin/bash /etc/cron.hourly/mcelog.cron
root       486   484  0 Nov17 ?        00:00:00 awk -v progname=/etc/cron.hourly/mcelog.cron progname {?????   print progname ":\n"?????   progname="";????       }????       { pri
nt; }
root       487   485  0 Nov17 ?        00:00:00 cat /sys/hypervisor/uuid
root       528  5278  0 Nov21 ?        00:00:00 crond
root       530   528  0 Nov21 ?        00:00:00 /bin/bash /usr/bin/run-parts /etc/cron.hourly
root       531   530  0 Nov21 ?        00:00:00 /bin/bash /etc/cron.hourly/mcelog.cron
root       532   530  0 Nov21 ?        00:00:00 awk -v progname=/etc/cron.hourly/mcelog.cron progname {?????   print progname ":\n"?????   progname="";????       }????       { pri
nt; }
应该是打开/sys/hypervisor/uuid文件数过多，经检查发现问题根源出在/etc/cron.hourly/mcelog.cron脚本
#more 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
手动执行cat /sys/hypervisor/uuid，执行后就没有反映了，一直在等待。上网搜索说是linux内核的一个小Bug，将脚本中相应语句注视掉，重启服务器，恢复正常。

相关文档：
cat /sys/hypervisor/uuid 阻塞
摘要：此带Xen的内核存在一个bug 能使cat /sys/hypervisor/uuid 阻塞，而使系统负载变高。
rhels内核版本：2.6.18-164.el5
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来启动系统。
方法很多，任由你选吧。