Slurm 与 LSF 对比实测报告

执行日期：2026-09-11 | 对比环境：同一套硬件上的共存双调度器（非理论对比，均为真实取证） Slurm 26.05.2（控制节点 k8s-master-01） | IBM Spectrum LSF 10.1.0.0 build 600545 LSF 访问方式：root 直连被拒（bqueues/bhosts 返回 User permission denied）， 必须使用 lsfadmin（admin_group 成员）：su - lsfadmin -c 'export PATH=/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/bin:$PATH; bqueues'

---

一、并存格局实测

两侧共用同一组计算节点（k8s-node-01/02/03），账号体系完全对应，这是本集群最值得注意的特征：

维度	Slurm	LSF
控制节点	k8s-master-01 (192.168.0.2)	k8s-master-01（master）、k8s-master-02（backup）
计算节点	k8s-node-01/02/03	k8s-node-01/02/03（compute_group）
队列/分区	4 分区：interactive(4h)、compile(24h,默认)、regression(8h)、long(72h)	3 队列：eda_short(60min)、eda_license(1440min)、eda_long(2880min)
账号/用户组	accounts：teama、teama1、teamb、teamb1、teamc、teamc1、dev、it、ops、root	user groups：teama、teama1、teamb、teamb1、teamc、teamc1、eda_group、admin_group
用户	rain01/02/03、cloud01、cy01、david01、lws01、cq01	同名用户（lsb.users 中逐个登记 MAX_PEND_JOBS）
调度器版本	26.05.2	10.1（2021-06-10 build）

账号一一对应意味着可以把同一批用户的业务在两侧平滑迁移，策略可逐条对照翻译。

LSF 进程角色实测（ps 取证）

/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/lim       # Load Information Manager，负载采集
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/res
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/sbatchd   # 每个执行主机上的作业执行守护
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/pim       # Process Information Manager，进程追踪
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/melim
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/elim.hpc  # External Load Information Manager（脚本）
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/mbatchd   # Master Batch Daemon（总控）
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/mbschd    # Master Batch Scheduler Daemon（调度决策，以 lsfadmin 身份运行）
/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/etc/eauth -s  # 认证服务

架构组件映射

职责	Slurm	LSF
总控/状态机	slurmctld	mbatchd
调度决策	slurmctld 内调度线程（sched/backfill 插件）	独立进程 mbschd（与 mbatchd 分离，以 lsfadmin 运行）
节点执行守护	slurmd	sbatchd
资源/负载采集	slurmd 采集（CPU 分配账本）	lim + pim + elim（负载阈值模型）
记账	slurmdbd + MySQL	mbatchd 内部事件（lsb.events）+ bacct
认证	munge（共享密钥 + 时间戳）	eauth（常驻认证服务）
资源隔离	cgroup（v1，cgroup.conf）	无 cgroup 硬限；队列级 MEMLIMIT/PROCESSLIMIT
高可用	SlurmctldHost 多行 + slurmdbd HA	master + backup 双活切换（本集群 k8s-master-02 为 backup）

关键结构差异：LSF 把"调度器"独立成 mbschd 进程，可单独重启/限流；Slurm 的调度逻辑在 slurmctld 线程内， 由 SchedulerParameters（含 max_rpc_cnt 等）控制其让锁行为。这解释了 LSF 为何能配 JOB_SCHEDULING_INTERVAL=1（秒级调度会话）。

---

二、命令映射总表（全部在本集群验证可执行）

2.1 作业提交

用途	Slurm	LSF
批量脚本提交	sbatch script.sh	bsub < script.sh / bsub -q eda_short "cmd"
资源申报	-n 2 --mem=1024M	-n 2 -R "rusage[mem=1024]"
指定队列/分区	-p compile	-q eda_short
作业名	-J name	-J name
输出重定向	-o file -e file	-o file
依赖	--dependency=afterok:<id>	-w "done(<id>)"
数组作业	--array=1-10	-J "name[1-10]"
交互式	salloc / srun --pty bash	bsub -Is
实时并行任务	srun -n 8 app	bsub -n 8（MPI 经 blaunch/blmpirun）
资源需求表达式	固定选项（--gres、--constraint、--mem）	-R "select[...] order[...] rusage[...] span[...]" 表达式语言
时限	-t 00:30:00	-W 30（分钟）或依赖队列 RUNLIMIT

资源需求表达式对照（LSF 的 -R 是其最有辨识度的设计）

LSF :  bsub -q eda_short -n 2 -R "rusage[mem=1024]"
Slurm: sbatch -p compile -n 2 --mem=1024M

本集群实测 bhist 中 LSF 回显的"有效资源需求"：

Effective RES_REQ <select[type == local] order[r15s:pg] rusage[mem=1024.00]>

即 LSF 把资源需求解析为 select（候选主机筛选）+ order（排序依据：先 r15s 再 pg）+ rusage（资源预留）， 调度决策直接建立在负载指标之上；Slurm 没有等价表达，靠"资源账本 + 约束表达式（--constraint）+ 优先级"。

2.2 查询

用途	Slurm	LSF
队列/分区概览	sinfo -o "%20P %6a %10l"	bqueues -w
队列详细参数	scontrol show partition	bqueues -l <queue>
节点状态	sinfo -N -o "%12N %8T %10C"	bhosts / bhosts -l <host>
实时负载	scontrol show node（CPU/内存分配账本）	lsload / lsload -l（11 项负载指标 r15s/r1m/r15m/ut/pg/io/ls/it/tmp/swp/mem）
作业队列	squeue	bjobs -w
含历史作业	squeue --start（预测） / sacct	bjobs -a / bhist
单作业详述	scontrol show job <id>	bjobs -l <id>
作业输出	sattach <id>.0 / 读文件	bpeek <id>
集群总览	sdiag	badmin showstatus
参数总览	scontrol show config	bparams -l

实测数据对照（同一时刻）：

# Slurm
k8s-node-01  mixed     2/14/0/16  32010     # Allocated/Idle/Other/Total CPU + RealMemory(MB)

# LSF
HOST_NAME     STATUS  JL/U  MAX  NJOBS  RUN  SSUSP  USUSP  RSV
k8s-node-01   ok         -   20      2    2      0      0    0     # MAX=20 slot

# LSF lsload（负载指标）
HOST_NAME     status r15s  r1m r15m   ut    pg   io    ls     it   tmp   swp   mem
k8s-node-01   ok      0.0  0.0  0.2   2%   0.0  583     0   7281   76G    0M 28.9G

对比要点：Slurm 展示"资源分配账本"（2/14/0/16），LSF 展示"负载与槽位占用"（MAX 20 / RUN 2 + 负载 11 项）。 Slurm 关心"还能分出去多少"，LSF 关心"机器现在有多忙"。

2.3 管控与记账

用途	Slurm	LSF
取消作业	scancel <id> / scancel -u user	bkill <id> / bkill -J name / bkill -u all
挂起/恢复	scontrol suspend/resume <id>	bstop / bresume
作业重排队	scontrol requeue <id>	brequeue <id>
改作业属性	scontrol update job <id> ...	bmod -n/-q/-R <id>
节点排空	scontrol update NodeName=X State=DRAIN	badmin hclose <host>
恢复节点	scontrol update NodeName=X State=RESUME	badmin hopen <host>
记账查询	sacct / sacctmgr	bacct -l <id>
事件时间线	journalctl -u slurmctld（原始文本）	bhist -l <id>（结构化状态机事件流）
利用率报表	sreport cluster utilization	bacct 汇总 / RTM（需额外组件）
公平份额	sshare / sprio	bqueues -l + fairshare 配置（lsb.params）

LSF bhist 是本集群记账粒度最细的工具（实测输出）：

Fri Sep 11 12:17:49: Submitted from host <k8s-master-01>, to Queue <eda_short>, 2 Task(s), Requested Resources <rusage[mem=1024]>;
Fri Sep 11 12:17:49: Dispatched 2 Task(s) on Host(s) <k8s-node-01> <k8s-node-01>, Allocated 2 Slot(s) on Host(s) <k8s-node-01> ...
Fri Sep 11 12:17:49: Starting (Pid 8613);
Fri Sep 11 12:17:50: Running with execution home </home/lsfadmin>, Execution CWD </home/lsfadmin>, Execution Pid <8613>;
Fri Sep 11 12:18:15: Done successfully. The CPU time used is 0.1 seconds;
Fri Sep 11 12:18:15: Post job process done successfully;

Slurm 等价信息需拼接 sacct（终态）+ journalctl -u slurmctld（中间态），无单一命令。

---

三、同作业双提交实测（核心实验）

3.1 作业定义

同一业务指令、同等资源（2 核 / 1GB / 25 秒）、同一节点组：

# Slurm（以 EDA 用户 rain01 提交；注意其登录 shell 为 /bin/csh）
su - rain01 -s /bin/bash -c "export PATH=/usr/local/slurm/bin:\$PATH; cd /tmp; \
  sbatch -p compile -n2 --mem=1024M -t 00:05:00 --job-name=SLURM_SIDE --wrap 'hostname; nproc; sleep 25'"

# LSF（以 lsfadmin 提交）
su - lsfadmin -c "export PATH=/opt/lsf/10.1/linux2.6-glibc2.3-x86_64/bin:\$PATH; \
  bsub -q eda_short -n 2 -R \"rusage[mem=1024]\" -J LSF_SIDE -o /tmp/lsf_out.%J \"hostname; nproc; sleep 25\""

3.2 实测结果

=== 提交时刻（同一秒）===
Slurm 12:17:48  ->  Submitted batch job 427
LSF   12:17:48  ->  Job <714> is submitted to queue <eda_short>.

=== 运行中（提交后 12 秒）===
Slurm: 427 SLURM_SIDE rain01 normal R TIME=0:13 CPUS=2 NODELIST=k8s-node-01
LSF  : 714 lsfadmin RUN eda_short  FROM=k8s-master-01  EXEC_HOST=k8s-node-01:k8s-node-01

=== 完成后 ===
Slurm: 427 COMPLETED  Elapsed=00:00:27  AllocCPUS=2  ReqMem=1G
LSF  : 714 done       TURNAROUND=26s   CPU_T=0.08  MEM=2M  HOG_FACTOR=0.0029

3.3 对比结论

观察项	Slurm	LSF
派发延迟（资源空闲）	≈0（提交后 ≤12s 内已 RUNNING，受 30s 调度周期影响）	0 秒（Submitted 与 Dispatched 同一秒）
资源计量单位	CPU（AllocCPUS=2）	Slot（Allocated 2 Slot(s)）
调度目标主机	k8s-node-01（CPUS 2/14 占用）	k8s-node-01（2 slot / 20 slot 占用）
记账字段	Elapsed/AllocCPUS/ReqMem/MaxRSS/ExitCode	CPU_T/WAIT/TURNAROUND/STATUS/HOG_FACTOR/MEM/SWAP
事件时间线	需 journalctl 拼接	bhist -l 单命令给全
取消	scancel（作业即刻消失，sacct 记 CANCELLED）	bkill（回显 Job <715> is being terminated，终态 EXIT）

派发延迟的差异根源：Slurm 侧 SchedulerParameters 含 defer（提交时不单独调度，等周期循环，实测 sdiag 为 2 cycles/min）； LSF 侧 JOB_SCHEDULING_INTERVAL=1 + MBD_SLEEP_TIME=10，提交即触发派发。 业务含义：LSF 在"短作业高并发"下起跑更快；Slurm 的 defer 是为"大批量提交时的系统响应性"做的取舍， 若追求低延迟可去掉 defer（代价是大批量提交时 slurmctld 压力上升）。

---

四、资源模型差异（本集群独有数据）

项	Slurm	LSF
单节点可调度单位	16 CPU	20 slot（lsb.hosts 中 MXJ=20）
单位含义	独占 1 个物理核	作业槽位（可超配，与实际核数脱钩）
主机折算因子	无	CPUF=12.50（bhosts -l 显示）
内存约束	DefMemPerCPU=2048 → 默认按核推内存；cgroup 硬限	队列 MEMLIMIT：eda_short 4G / eda_license 6G / eda_long 6G
进程约束	无队列级进程数限制（靠 cgroup）	队列 PROCESSLIMIT：eda_short 2 / 其他 4
时长约束	分区 MaxTime：4h/24h/8h/72h（按分区切换）	队列 RUNLIMIT：60min/1440min/2880min（绝对，ABS_RUNLIMIT=Y）
调度可行性判据	资源账本是否够（CPU/内存/GRES）	资源 + 负载阈值（loadSched/loadStop，本集群全为 - 即不判负载）
超卖	OverSubscribe 分区级（interactive=YES:4，其余 NO）	slot 天然可超配（20 slot vs 16 核）

本集群实测的重要差异：LSF 每节点 20 slot > Slurm 每节点 16 CPU。 LSF 的 slot 数配置为 20（超过物理核数），说明 LSF 侧允许更激进的超配； 而 Slurm 侧 compile/regression/long 分区 OverSubscribe=NO（严格独占）， 只有 interactive 分区允许 YES:4 超卖（阶段 5 F7 已实测超卖导致 3.68x 性能膨胀）。 迁移注意：把 LSF 上"按 slot 提交"的作业直接翻译为"按 CPU 提交"，实际算力密度会显著下降（20→16，且不再超配），需重新做容量评估。

限额配置对照

限额维度	Slurm 实现	LSF 实现
用户并发作业数	QOS MaxJobsPU（实测未生效，见 D4） / assoc MaxJobs	lsb.users 中每个用户的 MAX_PEND_JOBS（实测 rain01/02/03/cloud01/eda_dev 均为 100）
用户提交数	QOS MaxSubmitJobsPU（实测未生效）	MAX_PEND_JOBS 同时约束待处理队列
资源配额	MaxTRESPU=cpu=8（实测生效，路径见 D4）	队列 MEMLIMIT/PROCESSLIMIT + fairshare
账号级	account assoc MaxTRES/GrpTRES	lsb.resources 中的 resource quota / SLA
全局	MaxJobCount=100000	MAX_JOB_NUM=10000（事件保留数）

---

五、优先级与抢占对比

5.1 优先级

维度	Slurm	LSF
优先级来源	9 因子加权总分（priority/multifactor）	队列 PRIORITY + NICE + fairshare
队列/分区优先级	分区 PriorityTier（本集群均为 1）+ QOS Priority（100/50/20/10）	队列 PRIORITY：eda_short 50 > eda_license 40 > eda_long 30
用户级公平	FairShare 因子（权重 10000，实测 rain01 1111 vs rain03 3333）	由 fairshare 策略独立计算
可观测性	sprio -l 逐因子分解 + sprio -w 权重表，可完整验算	无等价单命令，需查 bqueues -l + mbschd 日志
重算周期	PriorityCalcPeriod=5min	随调度会话

Slurm 的可解释性明显更强：sprio -l 能直接看到每个因子的分值贡献，本次已把公式完全还原（见 QOS抢占与优先级实操.md）。

5.2 抢占（本集群最显著的配置差距）

维度	Slurm	LSF
是否启用	已启用：PreemptType=preempt/qos	未启用：lsb.queues 中无任何 PREEMPTION= 关系
抢占规则来源	数据库 QOS 的 Preempt= 列表（interactive 可抢占 long,normal）	需在队列间配置 PREEMPTION=PREEMPTIVE 或 PREEMPTION=FAIRSHARE（当前为空）
被抢占动作	QOS PreemptMode：interactive/normal=requeue、regression=cluster、long=suspend	未配置则不发生抢占
豁免期	PreemptExemptTime=30min（实测：抢占者 StartTime 被排期到豁免期满）	无对应概念；有 PREEMPTION_WAIT_TIME=300s 参数（当前为默认值，未配关系）
实测行为	受害者 QOS=normal → 立即 requeue（日志 preempted JobId=... has been requeued）；受害者 QOS=long → 静默不抢占（缺陷 D2）	全部队列 NJOBS=0，无法实测抢占；仅体现"高 PRIORITY 队列先取资源"

结论：本集群 LSF 侧是"优先级排队匹配"（priority-based matching），Slurm 侧是"优先级排队 + QOS 抢占"（含 requeue/suspend 语义）。 但 Slurm 侧的抢占链因 D1 + D2 两个缺陷，当前在生产中实际也无法触发（作业不带 QOS + long 用 suspend 模式）， 属于"纸面能力强于实际能力"，必须按 D1/D2 修复后才能真正兑现。

---

六、记账与 License 对比

维度	Slurm	LSF
存储	MySQL（经 slurmdbd），保留期长，支持跨期报表	mbatchd 内部事件文件（lsb.events），MAX_JOB_NUM=10000 上限
查询工具	sacct（作业明细）、sacctmgr（实体管理）、sreport（聚合报表）、sshare（份额）	bacct（汇总）、bhist（时间线）、bacctmgr
TRES 维度	cpu/mem/energy/node/billing/fs/disk/vmem/pages + license/*（14 项 License）	内置 CPU/内存/槽位；License 需 LSF License Scheduler 组件
License 实测	scontrol show licenses 已联通远程 FlexLM：ads@27000@k8s-master-02 Total=8 Free=8 Remote=yes（14 个 EDA 工具 License 全部登记）	队列 eda_license（PRIO=40）为 License 作业预留通道（实际用 License Scheduler 需额外配置）
报表能力	sreport cluster utilization / AccountUtilizationByUser / user TopUsage	bacct 汇总，复杂报表需 RTM/自建解析

本集群 Slurm 的 License 记账是完整的：AccountingStorageTRES 已含 license/ads, license/ams_sim, license/assura_drc, license/assura_lvs, license/calibredrc, license/calibrelvs, license/calibreperc, license/calibrexact, license/calibrexrc, license/ncsim 等 14 项， 且 scontrol show licenses 显示 Remote=yes、LastUpdate 为分钟级新鲜时间戳，说明 license 服务器轮询链路正常工作。 EDA 场景可据此做"License 感知的排队"（阶段 3 已规划，QOS MaxTRESPU=license/xxx 可用于限额）。

---

七、选型与迁移结论

7.1 能力对比小结

能力	胜出方	依据
可解释的优先级	Slurm	sprio -l 逐因子分解，可完整验算
派发延迟	LSF	实测 0 秒 vs Slurm 受 30s 周期/defer 影响
作业事件可追溯	LSF	bhist -l 单命令给完整状态机
资源隔离强度	Slurm	cgroup 硬限 + TRES 记账（LSF 无 cgroup 层）
抢占能力	Slurm（设计上）	QOS 抢占链 + requeue/suspend；但本集群因 D1/D2 实际未生效
负载感知调度	LSF	11 项负载指标 + loadSched/loadStop 阈值；Slurm 无等价机制
超配灵活性	LSF	20 slot/节点；Slurm 严格独占（除 interactive 分区）
记账/报表	Slurm	slurmdbd + sreport 多维聚合；LSF 需额外组件
License 调度记账	Slurm	14 项 license TRES 已联通 FlexLM 且记账完整

7.2 迁移注意（LSF → Slurm）

1. 资源申报翻译：-n 2 -R "rusage[mem=1024]" → -n 2 --mem=1024M；LSF 的 -R select/order 表达式在 Slurm 中要拆解为 --constraint（对应 select）+ 由调度器自行排序（无 order 等价物）。
2. 时限翻译：LSF -W 30（分钟）→ Slurm -t 00:30:00；队列 RUNLIMIT 需翻译为分区 MaxTime 或 QOS MaxWall。
3. slot → CPU 换算：LSF slot（20/节点）不能 1:1 换算为 Slurm CPU（16/节点）， 且 Slurm 的 compile/regression/long 为 OverSubscribe=NO，原有超配作业迁移后可能大面积 PD，必须先做容量重估。
4. 作业数限制：LSF MAX_PEND_JOBS=100 在 Slurm 侧需用 QOS MaxSubmitJobsPU 表达， 但该限额实测未生效（D4），迁移前必须验证或改用 TRES 表达。
5. 抢占语义差异：LSF 的"高优先队列优先取资源"是排队择优（不做抢占动作）， Slurm 若期望等价效果，需保证 ① 作业带正确 QOS（D1）② 受害者 QOS 的 PreemptMode 可用（D2）。
6. 提交账号与环境：EDA 用户登录 shell 为 /bin/csh，Slurm/LSF 的环境加载脚本需分别适配； LSF 管理命令必须用 lsfadmin，不能用 root。
7. 记账对齐：两侧账号体系已一致（teama…），可平行运行做用量对账；Slurm 侧以 sacct/sreport 为准， LSF 侧以 bhist/bacct 为准，建议按周做一次双侧用量核对。

---

来源：/home/rain/Documents/slurm/slurm_study/slurm_study_plan/阶段6_进阶与对比/Slurm与LSF对比实测.md ｜ 最后更新：2026-09-11 12:27（由 build/sync.py 同步，请勿在站点侧修改）