MPI + Slurm 实战：作业调度与性能调优复盘
1. 场景：从"手动 mpirun"到"集群作业"
上一篇文章里我们都是手动 mpirun。在真实集群上，作业由 Slurm 统一调度：分配节点、绑定资源、排队执行。本文跑通两条提交路径（交互式 srun 与批处理 sbatch），把资源参数与 MPI 进程布局对齐，最后用 HPL 实测数据做一次调优复盘。
2. 方式一：srun 直接提交
--ntasks 指定总进程数，--ntasks-per-node 指定每节点进程数（对应 mpirun -perhost）：
bash
# 8 个节点，每节点 8 进程，共 64 个 MPI 进程
srun -N 8 --ntasks-per-node=8 -p hpc ./xhpl
# 或者显式指定总任务数
srun -N 8 --ntasks=64 -p hpc ./xhpl要点：Slurm 已经替你生成了 slurm.hosts（分配的节点列表），不需要再写 hostfile；srun 会自动按分配结果启动 MPI 进程。
3. 方式二：sbatch 批处理脚本
bash
#!/bin/bash
#SBATCH -J hpl-run
#SBATCH -N 8
#SBATCH --ntasks-per-node=8
#SBATCH -p hpc
#SBATCH -o hpl_%j.log
#SBATCH --exclusive
module load mpi
export I_MPI_FABRICS=shm:ofi
export FI_PROVIDER=tcp
export I_MPI_PIN=1
mpirun -np 64 -genv I_MPI_FABRICS shm:ofi -genv FI_PROVIDER tcp ./xhpl提交：sbatch run_hpl.sh。作业进入队列，squeue 查看状态，sacct 查看历史与耗时。
4. 进程布局与绑定：性能的第一道关
MPI 进程落在哪个核、走哪条网络路径，直接决定性能：
| 配置 | 作用 | 实测建议 |
|---|---|---|
--ntasks-per-node（/ -perhost） | 每节点进程数 | 与 CPU 拓扑匹配（如 104 核节点取 8~13 的约数） |
I_MPI_FABRICS=shm:ofi | 同节点走共享内存、跨节点走 OFI | 混合 fabric 的默认正确姿势 |
FI_PROVIDER=tcp | OFI 的 TCP provider | IB 环境用 verbs/mlx，RoCE 用 efa/tcp 视硬件而定 |
I_MPI_PIN=1 | 进程绑定到具体核 | 防止进程在核间迁移，减少缓存抖动 |
实测命令（Intel MPI，HPL 全规模运行的原生形态）：
bash
mpirun -perhost ${MPI_PER_NODE} -np ${MPI_PROC_NUM} \
-genv I_MPI_FABRICS shm:ofi -genv FI_PROVIDER tcp \
-hostfile hostfile5. 调优复盘：1 节点 104 核 → 80 节点实测
以实测集群为例（每节点 104 核、主频约 2.0 GHz、内存 1.5 TB/节点）：
单节点理论峰值（Rpeak）：
Rpeak = 104 核 × 2.0 GHz × 32 FLOPs/cycle = 6656 Gflops80 节点 HPL 实测关键参数：
| 参数 | 实测值 | 说明 |
|---|---|---|
| N（矩阵规模） | 3,145,728 | 约按内存 80%~90% 选取 |
| NB（分块） | 384 | 兼顾 cache 与通信粒度 |
| 进程网格 P×Q | 10 × 8 | 80 个进程，尽量方阵 |
| BCASTs | 0（1rg） | 1 级递归广播 |
| lookahead | 0 | 流水线深度 |
调优经验曲线（从单节点到多节点，效率递减规律）：
| 规模 | 关键做法 | 观察 |
|---|---|---|
| 1 节点（104 核） | 全核满载 + 绑定 | 效率最高，shm 通信零网络开销 |
| 4~8 节点 | 网格 P×Q 调方、NB 加大 | 网络成为次要瓶颈 |
| 36 节点 GPU+CPU | 分池调度，CPU 部分走独立作业 | 混合负载需避免争抢 |
| 80 节点 | N 随内存线性放大、P×Q 按拓扑排布 | 效率回落但整体吞吐上升 |
三条可复用的结论：
- 进程网格先调方再调大小：P×Q 越接近正方形，通信步数越少；网格应配合节点内核心数（如 10×8 对应 80 进程 = 8 节点 × 10 进程）。
- 网络 provider 选对比调参更重要：同节点 shm、跨节点直通，
FI_PROVIDER配错（如强制 verbs 走 TCP 环境）会让延迟高一个数量级。 - 内存换 N，通信换形状：N 决定问题规模（越大效率越高），NB/P×Q/BCAST 决定通信效率；先跑小规模确认形状，再放大 N。
6. 排障速查
| 现象 | 排查 |
|---|---|
mpirun: command not found | module load mpi 或 source /opt/intel/oneapi/setvars.sh |
| 作业排队不动 | squeue -u $USER 看优先级与分区；--exclusive 会等整节点空闲 |
| 跨节点延迟异常高 | 确认 FI_PROVIDER 与硬件匹配；ping-pong 小消息对比 |
| 结果随进程数变化 | 检查 MPI_Reduce 类型长度（MPI_LONG_LONG）、网格 P×Q 是否整除 |
| 效率突然跳水 | 检查进程是否被 I_MPI_PIN=0 迁移、NB 是否太小、lookahead 是否过深 |