香港高性能计算（HPC）集群中出现由于多核心CPU核心组失效导致的任务调度混乱问题。这个故障引发大量任务执行失败、系统调度失控及计算资源浪费。通过对硬件配置、系统日志、调度器行为以及微架构级别的深入排查，我们定位到了问题根因并提出了切实有效的解决方案。本分析可为其他同类型超算中心在应对CPU核心异常、NUMA不一致性及任务调度紊乱时提供参考与借鉴。
香港科研机构部署了一套基于Intel Xeon Platinum 8352Y（Ice Lake）处理器的HPC集群，每个计算节点配备：
- CPU：2×Intel Xeon Platinum 8352Y（32核/64线程，2.2GHz）
- 内存：512 GB DDR4 3200 MHz（NUMA架构）
- 操作系统：CentOS 8 Stream + Linux Kernel 5.14
- 调度器：Slurm 22.05
- 系统工具：lscpu、numactl、hwloc、ipmitool、EDAC驱动
集群在一次物理搬迁后，部分节点开始出现任务频繁失败、CPU占用率异常及任务堆积等现象，初步判断为调度混乱。
在一个节点（节点编号：hpc-node-17）上观测到以下问题：
- Slurm调度器显示该节点可用CPU核心为64，但实际任务运行时，只有32个核心响应。
- top 与 htop 显示部分CPU核心常驻idle状态，任务未分配。
- 使用 numactl –hardware 输出发现NUMA节点信息不对称：
available: 2 nodes (0-1)
node 0 cpus: 0-15,32-47
node 1 cpus: 16-31
node 1 missing: 48-63
硬件日志中使用 dmesg | grep EDAC 显示多个“Uncorrectable Machine Check Error on CPU 57”：
mce: [Hardware Error]: CPU 57: Machine Check Exception: 0 Bank 4: b200000000020005
故障排查过程
1. 确认物理核心状态
执行 lscpu -e 检查CPU核心是否在线：
lscpu -e=CPU,ONLINE,NODE
结果显示 CPU 48–63 显示为 OFFLINE。
使用以下命令尝试激活：
for cpu in {48..63}; do echo 1 > /sys/devices/system/cpu/cpu$cpu/online; done
部分核心（如 CPU57）无法重新激活，提示：
echo: write error: Invalid argument
说明核心物理损坏或被主板屏蔽。
2. BIOS及固件检查
- 进入BIOS检查发现部分“Core Group”被设置为“Disabled by BMC”，疑似BMC自动屏蔽故障核心组。
- 更新BIOS至最新版本后重新测试，情况无改善。
3. IPMI与BMC日志分析
使用以下命令获取系统事件日志：
ipmitool sel elist
输出显示如下记录：
CPU57 internal error, threshold exceeded
BMC action: Core group power gated
确认主板BMC在搬迁后因多次MCE错误主动屏蔽了一整组核心（48–63），影响了NUMA节点1的完整性。
4. 任务调度器适配问题
Slurm中未及时更新节点CPU Topology，仍认为节点有64个核心，导致任务在调度时尝试绑定到不存在的核心，进而产生失败或无响应。
使用以下命令查看 Slurm 配置：
scontrol show node hpc-node-17
显示：
CPUTot=64 CPULoad=35
CPUAlloc=64
问题根因分析
- 主因： CPU核心组（CPU48–63）物理故障，BMC检测到MCE错误后屏蔽该核心组。
- 次因： Slurm调度器未同步物理核心变更，仍按原始64核配置调度任务。
技术细节补充：
Intel Ice Lake处理器使用Tile-based Core Group架构，一组核心出现不可纠正错误（UECC/MCE）后，BMC可通过PCH或ME指令将整个Tile断电处理。
断电的Tile对应的核心在Linux内核层表现为“offline”，并无法手动上线。
此类故障不影响节点启动，但破坏了NUMA对称性，极易造成任务资源映射异常。
故障解决方案
1. 硬件层修复
建议更换存在MCE错误的CPU，特别是出现多次“Bank 4/5” Machine Check的核心组。
若短期无法更换：
- 在BIOS中手动屏蔽故障核心组，以保持系统稳定性。
- 更新BMC SEL日志，避免系统反复尝试启用无效核心。
2. 系统配置调整
修改 Grub 启动参数，显式屏蔽故障核心：
GRUB_CMDLINE_LINUX="... maxcpus=48"
更新 grub：
grub2-mkconfig -o /boot/grub2/grub.cfg
重启后验证核心数：
lscpu | grep '^CPU(s):'
3. 调度器同步
重新生成 Slurm 的节点配置文件（slurm.conf）并更新可用核心数：
NodeName=hpc-node-17 CPUs=48 RealMemory=500000 State=UNKNOWN
重新加载配置：
scontrol reconfigure
并使用 scontrol update NodeName=hpc-node-17 State=RESUME 恢复节点状态。
验证与效果
修复后，节点表现正常：
- top 与 htop 显示核心负载均匀。
- numactl –hardware 输出对称，NUMA节点不再丢失。
- Slurm调度器稳定运行，任务失败率显著下降。
附：任务失败率变化（单位：%）
- 故障前（正常）： 0.2%
- 故障期间：37.6%
- 修复后；0.4%
优化建议
本次故障揭示出以下关键点：
- 硬件异常可能以微小症状表现，需结合系统日志进行深入挖掘。
- NUMA架构中任意核心组的失效，都会破坏调度一致性，需同步更新系统与调度器信息。
- 建议定期使用EDAC、IPMI、MCE工具巡检CPU核心状态。
建议工具链：
- 核心检测：lscpu, hwloc-ls
- MCE分析：mcelog, edac-util
- 调度器调试：scontrol, sinfo, sdiag
- 系统健康巡检：ipmitool sel list, smartctl, numactl
通过本次故障排查案例，团队建立了《节点级CPU故障快速排查手册》，并计划在后续集群扩容中采用支持RAPL/telemetry的处理器架构以便于早期检测。
