📚 课程目录第2章 EPYC架构与关键监控指标

2. EPYC架构与关键监控指标

要对AMD EPYC服务器做有效的监控告警与容量运营，第一步不是去调阈值，而是先弄清楚“指标是从哪块硅片上产生的”。EPYC的监控数据并非来自一个统一的中央计数器，而是分散在CCD、IOD、内存控制器、PCIe Root Complex等不同物理单元中。理解这些单元的职责边界，才能判断一个温度、功耗或错误计数究竟代表什么，以及它异常时该往哪个方向排查。

从CCD、CCX到IOD：指标产生的物理位置

以EPYC 9004系列（Genoa）为例，一颗处理器由多个CCD（Core Complex Die，核心复合体裸片）和一颗中央IOD（I/O Die）通过Infinity Fabric互连组成。每个CCD内部包含两个CCX（Core Complex），每个CCX通常有8个Zen 4核心，共享32MB L3缓存。也就是说，8核CCX是L3和核心频率的监控粒度，而CCD是温度与功耗的监控粒度。

IOD则集中了内存控制器（UMC）、PCIe 5.0通道、Infinity Fabric控制器、安全处理器和系统管理单元。关键点在于：内存带宽、PCIe链路状态、跨插槽互连流量这些指标全部由IOD侧产生，而核心频率、L3命中、每核心功耗则由CCD侧产生。监控工具读取的传感器路径不同，采样周期和精度也不同。

温度与功耗：从Tctl到Package Power

EPYC的温度监控有两个常用读数：Tctl和Tdie。Tctl是控制温度，通常带有厂商设定的偏移量，用于驱动风扇策略；Tdie是实际结温。在EPYC 9004上，两者在多数情况下接近，但Tctl可能因偏移而偏高。监控告警应优先关注Tdie，同时把Tctl作为风扇调速的参考。温度传感器分布在每个CCD上，因此一颗16核或32核的EPYC可能报告多个温度点，取最大值作为告警依据更合理。

功耗方面，Package Power是整个插槽的功耗，由SMU汇总上报。EPYC 9004的默认TDP范围从200W到400W不等，但实际运行中SMU会根据当前负载和散热能力动态调节。需要特别注意的是PPT（Package Power Tracking）——它是短时功耗上限，通常高于TDP。如果监控只盯着TDP，可能会漏掉PPT被持续打满导致的降频风险。建议同时采集“当前Package Power”和“SMU功耗封顶计数”，后者增加说明处理器正在被迫降频。

频率与带宽：核心、内存、互连三条线

核心频率的监控粒度是每核心或每CCX。EPYC支持Boost频率动态调整，因此“当前频率”波动很大，直接设固定阈值容易误报。更实用的做法是监控“有效频率”——即单位时间内实际执行的指令周期折算值，或者监控“频率低于基频的持续时间”。如果某CCX长时间低于基频，说明该区域可能触发了热限制或功耗限制。

内存带宽由UMC上报，12通道DDR5-4800的理论总带宽约460 GB/s。监控时应区分读带宽、写带宽和总带宽，并关注ECC错误计数。ECC CE（可纠正错误）少量出现属于正常，但UE（不可纠正错误）一旦出现就应立即告警，因为它意味着数据可能已损坏。PCIe侧则要关注链路速率和宽度是否发生降级，以及AER（高级错误报告）中的Correctable/Uncorrectable错误计数。

错误计数：RAS体系下的告警优先级

EPYC的RAS体系把错误分为CE、UE和Deferred三类。监控告警的优先级建议如下：

错误类型	典型来源	告警级别	建议动作
ECC CE（可纠正）	UMC / L3缓存	警告	记录趋势，单DIMM持续增长则安排更换
ECC UE（不可纠正）	UMC / 缓存	严重	立即隔离页面，评估是否下线维护
PCIe AER Correctable	PCIe RC / 端点	警告	检查链路误码率，观察是否伴随降速
PCIe AER Uncorrectable	PCIe RC / 端点	严重	检查设备状态，必要时重启或更换
xGMI链路错误	Infinity Fabric	严重	检查插槽间互连，评估双路通信影响

监控采集的实操要点

在Linux下，可以通过rasdaemon采集RAS事件，通过amd_energy驱动读取每CCD功耗，通过lm-sensors读取温度。以下是一个采集示例：

# 查看EPYC温度与功耗
sensors | grep -E "Tctl|Tdie|Package"

# 查看ECC错误计数（需rasdaemon运行）
ras-mc-ctl --error-count

# 查看PCIe AER错误
ras-mc-ctl --aer-errors

# 查看每CCD功耗（amd_energy驱动）
cat /sys/class/hwmon/hwmon*/energy*_input

采集频率建议：温度与功耗每5～10秒一次，ECC和AER错误每30～60秒一次。频率过高会增加SMU负担，频率过低则可能漏掉瞬态峰值。告警阈值不要照搬厂商规格书，而应基于基线——先采集一周的正常业务数据，取P95值作为警告线，P99值作为严重线，再结合业务SLA调整。

实操提示：EPYC的Tctl偏移量因型号而异，建议在BIOS或BMC中确认当前平台的Tctl偏移设置。如果Tctl与Tdie差值超过10°C，说明偏移较大，告警应以Tdie为准，避免风扇策略被误导。

总结来说，EPYC的监控指标不是孤立的数字，而是与CCD、IOD、UMC、PCIe RC等物理单元一一对应的。温度看CCD，功耗看SMU，带宽看UMC和xGMI，错误看RAS。把指标映射回架构，才能在告警响起时快速判断是散热问题、功耗墙、内存故障还是互连异常，也才能为后续的容量运营提供可靠的决策依据。