性能异常故障报告（F7：OverSubscribe 超卖绑定竞争 3.68x 膨胀）¶

故障时间¶

2026-09-10 学习窗口内实测（interactive 分区，OverSubscribe=YES:4，k8s-node-01）。

现象¶

64 进程基准程序（16 任务 × 每任务 fork 4 子进程）在 16 核节点上：
独占基线：40.2s
超卖竞争：148.0s
性能膨胀 3.68 倍；
竞争期取证：多个进程被调度到相同 CPU（绑定重叠），cgroup CPU 子系统显示多任务共享同组核；
期间系统仍"健康"：无报错、作业 RUNNING、ExitCode 0:0——性能问题不报错，只能靠基线对比发现。

影响范围¶

interactive 分区超卖窗口内的所有共存作业；间接拖慢依赖该分区的交互式调试/前后处理任务。

根因原理（双根因取证）¶

OverSubscribe 超卖：分区配置 OverSubscribe=YES:4 允许每核最多 4 个任务重叠；64 进程 > 16 物理核 → 上下文切换 + 缓存抖动 + 调度延迟，CPU 时间被摊薄。
绑定退化：超卖模式下 Slurm 的 CPU 绑定策略不再保证独占映射（task_info.sh 实测 rank→CPU 映射重叠），进程在核间迁移，L1/L2 缓存命中率下降。
第一性验证：基准耗时比 ≈ 进程数/核数的近似线性退化（64/16=4.0，实测 3.68x，差额为 fork 常态开销），证明瓶颈为 CPU 竞争而非 IO/内存。

证据摘要¶

# 提交端两次受挫（本身也是配置异常教学点）
srun -n16: error: Requested node configuration is not available
           ← 根因 DefMemPerCPU=2048 × 16 = 32768M > 32010M 物理内存（隐式内存放大）
           ← 解法: --mem-per-cpu=1900M (16×1900=30400M < 32010M)
srun -n64: error: More processors requested than permitted
           ← 根因 interactive QOS MaxTRESPU=cpu=16
# 最终实测
独占基线(16核16进程):  40.2 s
超卖竞争(16核64进程): 148.0 s   → 3.68x
[node] task_info.sh: rank→cpuset 映射重叠取证
[node] cgroup cpuset/cpu 配额显示多 rank 共享

解决方案¶

计算密集任务移出超卖分区：用 compile/regression（OverSubscribe=EXCLUSIVE 语义）或 long 分区独占跑。
确需超卖的交互/短任务：接受性能退化并设 walltime 上限，防长时间占位。
结构性调优：按业务把 OverSubscribe=YES:4 收敛为 YES（无限流）之外的可控档位，或对 interactive 分区设 QOS 限额控制总占用量（呼应 F6）。

验证结果¶

同基准在非超卖分区复测回落到基线量级（40s 档）；分区配置还原后与 EDA 规范基线一致。
性能膨胀可稳定复现：基线/竞争对比跑两次偏差 <5%。

预防建议¶

分区规划原则：超卖只给交互式/短小任务专区，生产算力分区一律独占（EDA 规范四分区即此意图）。
建立基准库：每分区一条标准基准（如本例 fork 基准），巡检定期跑，膨胀 >20% 告警。
用户教育：--oversubscribe 是主动让渡性能换取排队位，禁止在计算密集作业上使用。
提交侧预检：作业脚本检查 sinfo -p <分区> -O OverSubscribe，计算密集任务误投超卖分区时直接拒绝。
内存放大批量预检公式固化为脚本：DefMemPerCPU × 任务数 < 节点物理内存，否则先显式 --mem-per-cpu。

来源：/home/rain/Documents/slurm/slurm_study/slurm_study_plan/阶段5_故障排查/性能异常故障报告.md ｜最后更新：2026-09-10 20:56（由 build/sync.py 同步，请勿在站点侧修改）