📚 课程目录第2章 EPYC服务器硬件拓扑与关键组件

2. EPYC服务器硬件拓扑与关键组件

AMD EPYC 服务器不是“把 CPU 插上就能跑”的通用平台。它的稳定性表现，很大程度上取决于 CPU、内存、PCIe、存储、网卡与 BMC 之间的拓扑关系是否被正确识别、正确配置、正确监控。理解这些组件在稳定性验证中的角色，以及 NUMA 与 IODie/CCD 布局对故障定位的影响，是后续所有压测、日志分析和排障工作的基础。

一、从“一颗 CPU”到“多个计算单元”：EPYC 的内部布局

以 EPYC 9004 系列（Genoa）为例，一颗 CPU 内部并非单一计算核心，而是由多个 CCD（Core Complex Die）和一个 IOD（I/O Die）通过 Infinity Fabric 互连组成。每个 CCD 内含若干 Zen 4 核心与共享 L3 缓存；IOD 则集中承载内存控制器、PCIe 控制器、Infinity Fabric 链路以及安全处理器等。对操作系统而言，这些核心可能被划分为多个 NUMA 节点，而不是一个均匀的整体。

这种布局带来的直接后果是：内存访问延迟不再均匀。某个核心访问“本地”内存控制器所挂内存的速度，明显快于访问另一侧 IOD 所挂内存。稳定性验证中如果忽略这一点，就可能把“跨 NUMA 访问导致的性能抖动”误判为“CPU 或内存故障”。

二、NUMA 与 IODie/CCD 布局对故障定位的影响

在稳定性验证中，NUMA 配置直接决定了“谁访问谁”的延迟与带宽。以 NPS4 为例，一颗 32 核 EPYC 可能被划分为 4 个 NUMA 节点，每个节点包含 3 个 CCD 和对应的内存通道。此时如果某个压测进程被调度到 node 0，却大量访问 node 2 的内存，就会出现明显的跨节点延迟，表现为吞吐下降、延迟抖动，但硬件本身并无故障。

更隐蔽的情况是：某个 CCD 或某个内存通道出现可纠正错误（CE）时，如果验证程序没有按 NUMA 节点分别统计，错误就会被“平均”到整体数据中，难以定位。正确的做法是：在压测前先用 numactl --hardware 或 lscpu 确认节点与 CPU 的映射关系，再让压测工具按节点绑定运行，分别记录每个节点的带宽、延迟和错误计数。

# 查看 NUMA 节点与 CPU 映射
lscpu | grep -i numa
numactl --hardware

# 将压测绑定到 node 0 的 CPU 与内存
numactl --cpunodebind=0 --membind=0 ./stress-ng --cpu 8 --vm 4 --timeout 300s

# 查看各节点内存错误计数（示例路径）
grep -r "CE" /sys/devices/system/edac/mc/mc*/csrow*/ch*_ce_count

当出现 MCE（Machine Check Exception）时，日志中通常会携带 CPU 核心编号、CCD 编号或内存控制器地址。如果验证人员事先不清楚 CCD 与 NUMA 节点的对应关系，就只能看到“某个核心报错”，而无法判断是“单个核心问题”还是“整个 CCD 或 IOD 链路问题”。因此，建议在验证开始前绘制一张本机拓扑映射表，把物理槽位、NUMA 节点、CCD 编号、内存通道、PCIe 插槽一一对应起来。

三、各组件在稳定性验证中的具体职责

CPU 与 CCD：负责计算负载与中断处理。验证时关注核心温度、频率是否降频、是否出现 MCE、是否有个别核心持续跑偏。CCD 级故障往往表现为某一组核心同时异常，这时应优先检查该 CCD 对应的 Infinity Fabric 链路与供电。

内存：EPYC 平台通常启用 ECC。可纠正错误（CE）本身不致命，但短时间内大量 CE 往往预示 DIMM 或通道即将失效。验证时应持续采集 CE/UE 计数，并结合 DIMM 槽位与 NUMA 节点判断是单条内存问题还是通道问题。

PCIe 设备（GPU、NVMe、网卡）：关注 AER（Advanced Error Reporting）日志、链路速率是否从 Gen5 降到 Gen4/Gen3、是否出现设备掉线或超时。对于 NVMe，还要关注 I/O 超时与队列深度异常；对于网卡，关注丢包、CRC 错误与链路 flap。

BMC：它是稳定性验证的“黑匣子”。即使操作系统已经崩溃，BMC 仍能记录 SEL 日志、传感器越限、电源事件与温度曲线。验证前应确认 BMC 时间同步、SEL 日志级别、远程 KVM 可用，并定期导出日志作为时间线证据。

建议在验证开始前执行一次“拓扑基线采集”：记录 lscpu、numactl --hardware、lspci -tv、nvme list、ip -br link 以及 BMC SEL 清空后的初始状态。后续所有异常都可以与这份基线对比，快速判断是配置漂移还是硬件劣化。

四、从拓扑到排障：一个典型的定位思路

假设某台 EPYC 服务器在 72 小时压测中，第 40 小时出现一次系统无响应。重启后 BMC SEL 显示“CPU 温度越限”，操作系统日志中有 MCE 记录，指向 CCD 2 的某个核心。此时不应直接更换 CPU，而应按以下顺序排查：

确认散热器安装压力、导热硅脂状态与风扇转速曲线，排除散热问题。
检查该 CCD 对应的供电与 Infinity Fabric 链路是否有 AER 或降速记录。
用 numactl 将该 CCD 所属 NUMA 节点隔离，单独复现压测，观察是否再次触发 MCE。
若隔离后仍复现，再考虑 CPU 本体或主板 socket 问题；若不再复现，则可能是跨节点访问或散热不均导致。

这个过程中，NUMA 与 CCD 布局知识直接决定了“隔离复现”的粒度。如果不知道 CCD 与 NUMA 节点的对应关系，就只能整机复现，效率极低，且容易误换硬件。

总结来说，EPYC 服务器的稳定性验证不是单一组件的测试，而是对 CPU、内存、PCIe、存储、网卡与 BMC 之间拓扑关系的系统性检验。理解 NUMA 与 IODie/CCD 布局，能够把“整机不稳定”拆解为“某个节点、某个 CCD、某个通道”的具体问题，从而让故障定位从猜测走向可复现、可验证的工程过程。