Exadata计算节点的内存出现故障，导致CPU耗尽

案例概述

客户的一台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_gen_pool_add: 2 callbacks suppressed

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使用率降到正常水平，告警消失。

posted @ 2025-09-09 09:01 石云华阅读(42) 评论(0) 收藏举报

刷新页面返回顶部

Exadata计算节点的内存出现故障，导致CPU耗尽

公告