1. 课程导入与EPYC平台全景

在数据中心里，服务器稳定性从来不是一句口号，而是由处理器、内存、I/O、固件、散热与操作系统共同决定的结果。AMD EPYC 处理器凭借 Chiplet 架构、高核心密度和丰富的 PCIe 通道，已经成为云计算、虚拟化、数据库和高性能计算场景的重要平台。但核心数越多、拓扑越复杂，稳定性验证与故障诊断的难度也越高。本课程的目标，是帮助你把“服务器能开机”推进到“服务器在真实负载下长期可控、可观测、可定位”。

学习目标与整体框架

本课程围绕三条主线展开：稳定性验证、故障诊断和平台认知。稳定性验证关注的是“如何证明系统在给定条件下不会出错”，包括 CPU 压力、内存带宽、PCIe 链路、NUMA 亲和性、温度与功耗墙等；故障诊断关注的是“当系统出现异常时，如何从现象反推到根因”，包括 MCE 机器检查异常、EDAC 内存纠错、PCIe AER 报错、BMC 日志、内核日志和性能计数器。平台认知则是前两者的基础：你必须知道 EPYC 的代际差异、Chiplet 布局、内存通道数量、I/O Die 与 CCD 的关系，才能判断一个报错到底来自计算核心、内存控制器还是 I/O 路径。

整体框架可以理解为一条从“平台建模”到“验证执行”再到“诊断闭环”的链路。先建立平台基线，明确 CPU 型号、BIOS 版本、内存配置、NUMA 拓扑和固件策略；再设计验证用例，覆盖计算、内存、I/O、虚拟化和长时间老化；最后通过日志、计数器和测试工具定位异常，并把结论反馈到配置或硬件更换。这个闭环不是线性的，而是迭代的：一次诊断结果往往会改变下一次验证的边界条件。

EPYC 代际与架构特性

理解 EPYC 的稳定性问题，首先要理解它的代际演进。第一代 Naples（Zen）把 32 核带入单路市场，但内存通道和 I/O 由 SoC 直接提供；第二代 Rome（Zen 2）引入 Chiplet 设计，把计算核心拆成多个 CCD，每个 CCD 包含若干核心和共享 L3，再通过 Infinity Fabric 连接到中央 I/O Die。第三代 Milan（Zen 3）把 CCD 内核心数提升到 8 个，L3 缓存改为统一 32MB，降低了跨核心访问延迟。第四代 Genoa（Zen 4）支持 12 通道 DDR5、PCIe 5.0 和 CXL 1.1，核心数最高 96 核；Bergamo 则针对云原生场景优化了核心密度和能效。第五代 Turin（Zen 5）进一步提升了 IPC 和内存带宽，并继续扩展核心数。

这些代际差异直接影响验证策略。例如，Rome 和 Milan 的 NUMA 拓扑中，每个 CCD 是一个 NUMA 节点，跨 CCD 访问延迟明显高于 CCD 内部；Genoa 支持 NPS0/NPS1/NPS2/NPS4 等内存交织模式，不同 NPS 设置会改变内存延迟和带宽的分布。如果你在验证时忽略 NPS 设置，就可能把“配置导致的性能抖动”误判为“硬件故障”。同样，PCIe 5.0 的链路训练对信号完整性更敏感，AER 报错可能来自插槽、转接卡或线缆，而不是 CPU 本身。

典型应用场景与稳定性挑战

EPYC 服务器常见的应用场景包括：云计算与虚拟化、内存数据库、AI 推理与训练、高性能计算和存储节点。不同场景对稳定性的压力点不同。虚拟化场景关注 VM 密度、vCPU 调度和 NUMA 亲和性，常见问题是跨 NUMA 访问导致延迟抖动；内存数据库关注内存带宽和 ECC 纠错，常见问题是可纠正错误累积到阈值后触发降级；AI 推理关注 PCIe 带宽和 GPU 直连拓扑，常见问题是链路降速或 AER 风暴；HPC 关注浮点计算和 MPI 通信，常见问题是 AVX 频率墙和散热降频。

稳定性挑战可以归纳为四类：热与功耗、内存与缓存、I/O 与链路、固件与配置。热与功耗方面，EPYC 的 TDP 从 180W 到 400W 不等，散热设计不足会导致频率下降甚至热关机；内存与缓存方面，DDR5 的 ECC 和 RCD 参数对稳定性影响很大，缓存一致性错误可能表现为随机进程崩溃；I/O 与链路方面，PCIe 5.0 和 CXL 对插槽、线缆和固件版本敏感；固件与配置方面，BIOS 版本、AGESA 代码、NPS 设置和电源策略都可能引入非硬件故障。

从现象到根因的诊断思路

故障诊断的核心是“先分层，再收敛”。分层是指把问题定位到计算、内存、I/O 或固件层；收敛是指通过日志、计数器和替换法逐步缩小范围。例如，系统随机重启，先看 BMC SEL 是否有 CPU 温度或电源事件；再看内核日志是否有 MCE 或 AER；再看 EDAC 是否有内存错误；最后用 stress-ng 或 memtester 复现。如果压力测试能复现，说明问题与负载相关；如果空闲也复现，说明问题更可能在固件或硬件本身。