案例概述
客户的一台Exadata X3-2，从凌晨3点多开始，计算节点dm01dbadm01的CPU使用率直线飙升到100%，并且一直持续这个状态； 而另外一个计算节点的CPU使用率正常，只有8%左右。
故障分析
1、查看EM监控。
从主机的监控图可以发现几点：
(1). 凌晨3点13分开始，CPU的使用率突然直线飙升到100%。
(2). 在整个故障期间，内存使用平稳。
(3). 刚出现故障时，基本没有业务。
2、检查dm01dbadm01节点的资源使用情况。
可以发现几点：
(1). CPU的使用率的确高达100%。应用程序部分消耗67%，而内核部分消耗了29%。
(2). 剩余的物理内存还比较富余，有25G左右。SWAP总共24GB，目前使得了4GB。
(3). 从进程层面来看，进程使用的CPU比较分散，没有出现某一个进程占用了大量CPU的情况。
(4). 该节点上部署了多套数据库实例，每个数据库实例使用的CPU比例相当，没有出现某一个数据库实例占用大量CPU的情况。
(5). CPU使用率排名第一的进程是ds_agent进程。
3、结合当前的这些信息，作了初步分析。
(1). 建议立即关闭ds_agent进程。ds_agent进程是一个防病毒软件，以前遇到过一个案例，该防病毒软件竟然会杀掉数据库进程，导致数据库实例中止。所以，对这个进程没什么好感，为了防止这个进程在作妖，建议先关闭该进程。
(2). 系统已经使用了4GB的SWAP空间，可以检查下当前是否有swap in、swap out的行为。
(3). 本次故障，数据库异常引发CPU使用100%的可能性非常非常低。
4、客户关闭ds_agent进程后，CPU使用率仍然维持在100%，这说明不是ds_agent进程引发的故障。
5、执行vmstat命令检测。当前没有swap in、swap out的行为。
6、检查操作系统的message日志，发现大量异常日志。日志内容如下。
Sep 4 08:47:16 dm01dbadm01 kernel: mce_gen_pool_add: 2 callbacks suppressed
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce_gen_pool_add: 2 callbacks suppressed
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
Sep 4 08:47:16 dm01dbadm01 kernel: mce: MCE records pool full!
这表示系统检测到大量不可纠正的错误，其数量多到内核预留的存储空间都已经装满了。
7、检测硬件故障。
-> show faulty
Target | Property | Value
-------------------+-----------------------+-----------------------------------
/SP/faultmgmt/0 | fru | /SYS/MB/P1/D2
/SP/faultmgmt/0/ | class | fault.memory.intel.sb.dimm_ce
faults/0 | |
/SP/faultmgmt/0/ | sunw-msg-id | SPX86-8004-CE
faults/0 | |
/SP/faultmgmt/0/ | component | /SYS/MB/P1/D2
faults/0 | |
/SP/faultmgmt/0/ | uuid | bcf04e51-eb81-44d8-8be5-ac852e70ed
faults/0 | | 29
/SP/faultmgmt/0/ | timestamp | 2025-09-04/03:10:04
faults/0 | |
/SP/faultmgmt/0/ | system_component_firm | (ILOM)2020.05.13
faults/0 | ware_releases |
/SP/faultmgmt/0/ | system_component_firm | (ILOM)4.0.4.22.b
faults/0 | ware_versions |
/SP/faultmgmt/0/ | system_component_firm | Oracle Corporation
faults/0 | ware_manufacturer |
/SP/faultmgmt/0/ | serd_count | 0x9ce
faults/0 | |
/SP/faultmgmt/0/ | fru_rev_level | 50
faults/0 | |
/SP/faultmgmt/0/ | fru_serial_number | 00AD011315151F1CAF
faults/0 | |
/SP/faultmgmt/0/ | fru_manufacturer | Hynix Semiconductor Inc.
faults/0 | |
/SP/faultmgmt/0/ | fru_name | 16384MB DDR3 SDRAM DIMM
faults/0 | |
/SP/faultmgmt/0/ | fru_part_number | 001-0003-01,HMT42GR7MFR4A-PB
faults/0 | |
/SP/faultmgmt/0/ | system_component_manu | Oracle Corporation
faults/0 | facturer |
/SP/faultmgmt/0/ | system_component_name | SUN FIRE X4170 M3
faults/0 | |
/SP/faultmgmt/0/ | system_component_part | 7061808
faults/0 | _number |
/SP/faultmgmt/0/ | system_component_seri | 1318FML0X1
faults/0 | al_number |
/SP/faultmgmt/0/ | chassis_manufacturer | Oracle Corporation
faults/0 | |
/SP/faultmgmt/0/ | chassis_name | SUN FIRE X4170 M3
faults/0 | |
/SP/faultmgmt/0/ | chassis_part_number | 7061808
faults/0 | |
/SP/faultmgmt/0/ | chassis_serial_number | 1318FML0X1
faults/0 | |
/SP/faultmgmt/0/ | system_manufacturer | Oracle Corporation
faults/0 | |
/SP/faultmgmt/0/ | system_name | Exadata X3-2
faults/0 | |
/SP/faultmgmt/0/ | system_part_number | Exadata X3-2
faults/0 | |
/SP/faultmgmt/0/ | system_serial_number | AK00100738
faults/0 | |
/SP/faultmgmt/1 | fru | /SYS/MB/P1/D3
/SP/faultmgmt/1/ | class | fault.memory.intel.sb.dimm_ce
faults/0 | |
/SP/faultmgmt/1/ | sunw-msg-id | SPX86-8004-CE
faults/0 | |
/SP/faultmgmt/1/ | component | /SYS/MB/P1/D3
faults/0 | |
/SP/faultmgmt/1/ | uuid | b3f2af47-6915-caea-a6d0-d2b55099e3
faults/0 | | 8d
/SP/faultmgmt/1/ | timestamp | 2025-09-04/03:10:05
faults/0 | |
/SP/faultmgmt/1/ | system_component_firm | (ILOM)2020.05.13
faults/0 | ware_releases |
/SP/faultmgmt/1/ | system_component_firm | (ILOM)4.0.4.22.b
faults/0 | ware_versions |
/SP/faultmgmt/1/ | system_component_firm | Oracle Corporation
faults/0 | ware_manufacturer |
/SP/faultmgmt/1/ | serd_count | 0xf5ea
faults/0 | |
/SP/faultmgmt/1/ | fru_rev_level | 50
faults/0 | |
/SP/faultmgmt/1/ | fru_serial_number | 00AD011315152F1C89
faults/0 | |
/SP/faultmgmt/1/ | fru_manufacturer | Hynix Semiconductor Inc.
faults/0 | |
/SP/faultmgmt/1/ | fru_name | 16384MB DDR3 SDRAM DIMM
faults/0 | |
/SP/faultmgmt/1/ | fru_part_number | 001-0003-01,HMT42GR7MFR4A-PB
faults/0 | |
/SP/faultmgmt/1/ | system_component_manu | Oracle Corporation
faults/0 | facturer |
/SP/faultmgmt/1/ | system_component_name | SUN FIRE X4170 M3
faults/0 | |
/SP/faultmgmt/1/ | system_component_part | 7061808
faults/0 | _number |
/SP/faultmgmt/1/ | system_component_seri | 1318FML0X1
faults/0 | al_number |
/SP/faultmgmt/1/ | chassis_manufacturer | Oracle Corporation
faults/0 | |
/SP/faultmgmt/1/ | chassis_name | SUN FIRE X4170 M3
faults/0 | |
/SP/faultmgmt/1/ | chassis_part_number | 7061808
faults/0 | |
/SP/faultmgmt/1/ | chassis_serial_number | 1318FML0X1
faults/0 | |
/SP/faultmgmt/1/ | system_manufacturer | Oracle Corporation
faults/0 | |
/SP/faultmgmt/1/ | system_name | Exadata X3-2
faults/0 | |
/SP/faultmgmt/1/ | system_part_number | Exadata X3-2
faults/0 | |
/SP/faultmgmt/1/ | system_serial_number | AK00100738
faults/0 | |
果然有硬件故障，两根内存出现告警。内存出现告警的时间与CPU直线飙升至100%的时间完全吻合。
8、检查系统中的内存情况。
[root@dm01dbadm01 ~]# free -g
total used free shared buff/cache available
Mem: 251 203 41 0 7 43
Swap: 23 2 21
[root@dm01dbadm01 ~]#
可以看出，系统当前识别出来的内存数量仍然是256GB，也即那两根内存虽然出现了硬件告警，但没有完全坏掉，当前仍然可以使用，所以浪费了大量的CPU来检测这些内存告警。如果这两根内存真的完全坏掉，反而不会出现这个故障。
故障解决
紧急更换内存，CPU使用率降到正常水平，告警消失。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。