简介：面向在高性能计算与超算平台开展科研、课程实验和批量计算任务的学生、教师及运维人员，这份国科大超算中心 Slurm 作业调度系统使用指南梳理了从基本概念到常用命令的完整使用路径，可帮助读者理解队列、节点、作业与作业步之间的关系，并掌握资源申请、任务提交、状态监控和结果回收方法。压缩包仅含 1 个 PDF 文件，约 595KB，轻量便携，适合随查随用，也便于在实验环境或实际集群操作时快速翻阅。内容围绕 sinfo、squeue、scontrol show partition/node/job、srun、sbatch、salloc、sbcast、sattach 等命令展开，涵盖交互式、批处理与分配式提交方式，并给出串行、OpenMP、MPI、GPU 作业及环境变量、IO 重定向和常见示例，读者可据此对照实际操作、理解脚本参数并排查常见调度问题。已有 3359 人学习，适合作为超算入门到进阶阶段的手册型参考资料。
1. 在超算上排队：高性能计算入门第一课不是写代码，而是把作业交对
很多人第一次登上高性能计算集群，翻车点不在算法，而在登录节点敲了一句./a.out——轻则进程被系统清掉，重则登录节点被拖到同组人一起卡。这份 Slurm 用户指南（对应集群侧 19.05.5 版本）解决的正是这件事：它不讨论并行算法，只回答一个工程问题——在共享的超算里，你的进程怎样合法地拿到 CPU 核、内存、GPU，跑完，再把结果和账单拿回来。适合三类人：第一次上机做课程实验的学生、从本地工作站迁到集群的算法工程师、以及要给团队写提交规范的人。它把 sbatch、srun、salloc 三条提交路径，sinfo、squeue、scontrol、sacct 四条查询路径，以及作业脚本指令与环境变量的对应关系，压成了一本可以边查边用的手册。
2. 三条提交路径的选择：sbatch、srun、salloc 到底差在哪一步
Slurm 的提交命令看起来都能跑程序，实际差别在于「资源分配」和「任务加载」这两步是不是同一件事。搞混这一步，最常见的结果就是：以为自己在排队，其实是在登录节点裸跑；或者以为脚本提交完就安全了，结果关掉终端任务就没了。
2.1 资源分配与任务加载：三种模式的本质差异
把三种模式拆成两个动作看就清楚了。资源分配是向调度器要节点、核数、内存、GPU；任务加载是把你的可执行程序真正拉起在那些节点上。
srun把两步合成一步：提交请求、等资源、在分配到的节点上加载任务，全程占着你的终端。salloc只做第一步：资源批下来后，命令是在你提交作业的那个节点上执行的，典型用法是拿一个带 Slurm 环境变量的 shell，再在里面反复srun。sbatch则是批处理：提交立即返回，资源满足后在分配到的第一个节点上执行你的脚本，脚本内部可以再写多条srun。
还有一个容易被忽略的差异：salloc 的命令在提交节点执行，sbatch 的脚本在分配的首个计算节点执行。这意味着脚本里写相对路径读文件时，两者看到的当前目录可能一致也可能不一致——取决于SLURM_SUBMIT_DIR和环境变量传递策略，这一点后面第 5 章会展开。
| 命令 | 是否阻塞终端 | 命令/脚本在哪执行 | 终端断开后 | 典型场景 |
|---|---|---|---|---|
srun | 是 | 分配到的计算节点 | 任务终止 | 五分钟级的小规模验证 |
salloc | 是（拿到 shell 后） | 提交节点执行命令，srun落到计算节点 | 任务终止 | 反复调参、交互调试 |
sbatch | 否，立即返回 | 分配的首个计算节点 | 不受影响 | 长作业、生产任务 |
选型上我一般这么定：跑不超过十分钟、只想确认环境和程序能不能起来，用srun；要在同一个资源分配里反复改参数跑十几遍，用salloc；任何超过半小时或者要过夜的任务，一律sbatch，不给自己留后悔药。
2.2 srun 交互式：短作业验证的最小闭环
先用一条最朴素的命令确认资源能拿到、节点名对得上。下面这条申请 1 个节点、4 个任务，跑hostname：
# -N 节点数；-n 任务数（一般一个任务对应一个核）；-p 队列名；--time 墙上时间上限 srun -N 1 -n 4 -p CPU-Large --time=00:05:00 hostname执行后终端会挂住，等调度器把资源批下来才输出。-n 4的含义是启动 4 个任务，hostname会被拉起 4 次，正常情况下你会看到 4 行输出。如果只看到 1 行，先别怀疑集群，检查是不是把-n写成了-N。
加--label能让每行输出带任务编号，多任务场景下排查「哪个 rank 出了问题」非常省事：
# --label 让输出前缀带上任务号，方便定位是哪个进程报错 srun --label -n 4 -p CPU-Large hostnamesrun的边界要说清楚：它不是「后台提交」。终端一断，任务随之终止。所以有经验的用法是拿它做冒烟测试——先用一两分钟确认 module 加载对不对、输入文件路径通不通、MPI 能不能起，再把这套命令原样搬进 sbatch 脚本。
2.3 salloc：拿到 shell 之后再反复 srun
调参阶段最烦的是每改一次都要重新排队。salloc的价值就在这：一次性把资源占住，然后在同一个分配里跑很多次srun。
# 申请 2 个节点、共 64 个任务，占用 1 小时 salloc -N 2 -n 64 -p CPU-Large --time=01:00:00 # 资源批下来后，你会进入一个新的 shell，此时 SLURM_* 环境变量已就绪 srun hostname srun ./my_mpi_app exit # 退出 shell，资源立即释放如果不跟任何命令，salloc默认起/bin/sh，你拿到的是一个环境变量已经配好的 shell。这里有个成本意识：只要 shell 不退，节点就一直算你的机时。我见过有人salloc之后去吃饭，回来发现一小时的额度跑了四十分钟空转。所以用完立即exit，别把交互式分配当长期工位。
另一个容易踩的点：salloc分配的节点集合在你拿到 shell 时就固定了，shell 里再srun只会在这些节点上跑。想换节点，得先退出重新申请，不能靠srun --nodelist临时改。
2.4 sbatch：提交即返回的脚本骨架
批处理是这套系统的正餐。脚本头部用#SBATCH写指令，正文写你要跑的命令，最后sbatch提交。
#!/bin/bash #SBATCH --job-name=demo_mpi # 作业名，会出现在 squeue/sacct 里 #SBATCH --partition=CPU-Large # 队列名，以 sinfo 实际输出为准 #SBATCH --nodes=2 # 节点数 #SBATCH --ntasks-per-node=32 # 每节点任务数，2x32=64 个任务 #SBATCH --time=02:00:00 # 墙上时间上限，超时会被杀掉 #SBATCH --output=%x-%j.out # %x=作业名 %j=作业号，避免互相覆盖 #SBATCH --error=%x-%j.err module load intel/2019 # 模块名以 module avail 实际结果为准 srun ./my_mpi_app提交与观察：
sbatch run.sh # 返回形如 Submitted batch job 12345 squeue -j 12345 # 看状态，PD 排队 / R 运行中%x-%j这个占位符组合值得养成习惯。用固定文件名out.txt的后果是：上一次的结果被这一次覆盖，而你往往是在作业失败之后才想起来要对比上一次的输出。带上作业号，每次运行天然留档。
还有一点要提醒：脚本里的srun不是必须的，串行程序直接写./app也能跑；但只要是多进程程序，就应该用srun拉起，让 Slurm 知道任务和节点的映射关系，否则后续的sattach、作业步监控、信号传递都会失效。
3. 把作业脚本写成模板：串行、OpenMP、MPI、GPU 四份可直接抄的骨架
写脚本这件事，最怕的不是写错，是「看起来能跑」。下面四份骨架对应四类负载，每份都标了关键参数的取值逻辑，照着改队列名和程序名就能用。
3.1 #SBATCH 指令与命令行参数的对应关系
脚本里的#SBATCH和命令行参数是一一对应的，理解映射关系后就不需要背两套。
| 脚本指令 | 等价命令行 | 说明 |
|---|---|---|
--nodes/-N | -N | 申请的节点数，可写min-max |
--ntasks/-n | -n | 总任务数，一般等于总核数 |
--ntasks-per-node | — | 每节点任务数，与-N相乘应等于-n |
--cpus-per-task/-c | -c | 每个任务分到的核数，OpenMP 线程数靠它 |
--mem/--mem-per-cpu | 同名 | 每节点内存 / 每核内存，二选一 |
--gres | 同名 | 通用资源，GPU 写作gpu:2 |
--time/-t | 同名 | 墙上时间，格式D-HH:MM:SS |
--output/--error | -o/-e | 标准输出 / 标准错误重定向 |
--partition/-p | -p | 队列（分区）名 |
--qos | 同名 | 服务质量等级，影响优先级和限额 |
--nodelist/--exclude | 同名 | 指定或排除节点 |
--dependency | 同名 | 作业依赖，如afterok:12345 |
--exclusive | 同名 | 排它运行，独占节点 |
一个反向排查技巧：作业跑完后scontrol show job <id>会把你提交时的完整参数回显出来，包括你写在脚本里但被调度器改写的部分。脚本行为和预期不符时，先看这个回显，比盯着脚本猜快得多。
3.2 串行与 OpenMP：线程数要跟着 --cpus-per-task 走
串行作业最简单，申请 1 个任务、1 个核就够，但很多人忘了写内存，跑大数据时被 OOM 干掉。
#!/bin/bash #SBATCH -J serial_demo #SBATCH -p CPU-Large #SBATCH -N 1 #SBATCH -n 1 #SBATCH -c 1 #SBATCH --mem=4G # 单任务也要写内存，不写按队列默认值走 #SBATCH -t 00:20:00 #SBATCH -o %x-%j.out ./serial_app input.datOpenMP 的关键在于：线程不是靠-n给的，而是靠-c。-c 16表示这个任务独占 16 个核，Slurm 会把SLURM_CPUS_PER_TASK设成 16，你用它去设OMP_NUM_THREADS才不会和调度器打架。
#!/bin/bash #SBATCH -J omp_demo #SBATCH -p CPU-Large #SBATCH -N 1 #SBATCH -n 1 # 只有 1 个任务 #SBATCH -c 16 # 这个任务拿 16 个核 #SBATCH --mem=32G #SBATCH -t 01:00:00 #SBATCH -o %x-%j.out # 让 OpenMP 线程数严格等于申请的核数，避免超订被降速 export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK # 绑核，减少线程在核间跳动带来的抖动 export OMP_PROC_BIND=true ./omp_app如果写成-n 16而不写-c，得到的是 16 个单核任务，OpenMP 每个任务只能落到 1 个核上，性能会难看得让你怀疑编译器。这是最典型的「参数写反」类翻车。
3.3 MPI：不要在 srun 外面再套一层 mpirun
MPI 作业用--ntasks和--ntasks-per-node描述进程布局，进程由srun拉起。
#!/bin/bash #SBATCH -J mpi_demo #SBATCH -p CPU-Large #SBATCH -N 4 #SBATCH --ntasks-per-node=32 # 4x32=128 个 MPI 进程 #SBATCH -c 1 # 每个进程 1 核，别和 OpenMP 抢 #SBATCH --mem=0 # 0 表示用满节点内存，也可写具体值 #SBATCH -t 04:00:00 #SBATCH -o %x-%j.out module load openmpi/4.0.3 # 以集群实际模块为准 # 正确：由 Slurm 拉起 MPI 进程 srun ./mpi_app这里的血泪经验是：不要写mpirun -np 128 ./mpi_app。srun已经按--ntasks起了 128 个进程，再套一层mpirun就变成 128×128，轻则通信域炸掉，重则直接把节点内存吃光。判断依据很简单——作业日志里 MPI 初始化打印的进程数远大于你申请的任务数，就是套娃了。
另一个细节是--mem=0：它表示「把节点内存全给我」，只有在--exclusive独占节点时才安全。共享节点上这么写，调度器可能给你一个超出实际可用量的数字，最终仍然 OOM。
3.4 GPU 作业：--gres 写对，设备编号交给 Slurm
GPU 队列的资源申请走--gres，语法是名称:数量。
#!/bin/bash #SBATCH -J gpu_demo #SBATCH -p GPU-V100 #SBATCH -N 1 #SBATCH -n 4 # 4 个任务 #SBATCH -c 2 # 每任务 2 核，共 8 核 #SBATCH --gres=gpu:2 # 申请 2 块 GPU #SBATCH -t 02:00:00 #SBATCH -o %x-%j.out module load cuda/10.2 # 以集群实际模块为准 # 不要手动 export CUDA_VISIBLE_DEVICES，Slurm 会按 --gres 自动设置 srun ./gpu_app手动指定CUDA_VISIBLE_DEVICES=0,1是个隐蔽的坑：你以为指定了第 0、1 块卡，实际拿到的是调度器分给你的那两张卡的物理编号，两者往往对不上，结果是多个作业挤在同一张卡上互相拖慢。让 Slurm 去设这个变量，程序里读SLURM_JOB_GPUS或直接用 CUDA 默认枚举即可。
多任务多卡的映射也要留意：-n 4配--gres=gpu:2时，8 个可见设备槽位里有 2 个是真实卡，怎么分配取决于集群的gres配置。稳妥做法是先跑一次只打印设备号的短作业确认映射，再上正式任务。
3.5 脚本里能直接用的环境变量
Slurm 注入了一批环境变量，脚本里直接用，比硬编码路径可靠。
| 变量 | 含义 |
|---|---|
SLURM_JOB_ID | 作业号 |
SLURM_JOB_NAME | 作业名 |
SLURM_NTASKS | 总任务数 |
SLURM_NNODES | 节点数 |
SLURM_CPUS_PER_TASK | 每任务核数 |
SLURM_JOB_NODELIST | 分配到的节点列表 |
SLURM_SUBMIT_DIR | 提交作业时所在目录 |
SLURM_ARRAY_TASK_ID | 数组作业的当前下标 |
写日志目录时用$SLURM_JOB_ID拼路径，比任何手工命名都稳。要打印节点列表，用scontrol show hostnames $SLURM_JOB_NODELIST展开成一行一个，直接喂给需要主机列表的程序。
4. 查询链路：sinfo、squeue、scontrol、sacct 四层信息怎么串起来读
提交完作业，接下来全是读输出。这四个命令的粒度是递进的：sinfo 看集群有什么，squeue 看队列里有什么，scontrol show 看单个对象的全部细节，sacct 看已经消失的作业去了哪里。
4.1 sinfo：先确认队列名和节点状态
第一件事永远是sinfo，因为队列名每个集群都不一样，抄别人的脚本第一步就是把-p改对。
sinfo -l # 长格式，看时间限制、节点数、状态 sinfo -o "%20P %5a %10l %6D %6t %N" # 自定义列，适合贴进值班记录 sinfo -N -p GPU-V100 # 每行一个节点，看具体节点状态 sinfo -t idle,mixed -p CPU-Large # 只看空闲和部分占用的节点 sinfo -R # 只看不可用节点及其原因%t那列的状态要会读：idle全空、mixed部分占用（还能接新作业）、allocated全占、down宕机、drained已排空不再接新作业、draining正在排空。状态后面带*表示节点没响应，这种节点即使显示idle也接不了活，别在那儿反复重试。
sinfo -R是排查「为什么我的作业一直排队」的第一站。如果目标队列所有节点都是drained，那问题不在你的脚本，在运维。
4.2 squeue：把 REASON 字段当诊断书读
squeue的输出里，最值钱的是最后一列NODELIST(REASON)。
squeue -u $USER # 只看自己的 squeue -p GPU-V100 -t PD # 只看该队列排队中的 squeue -o "%.10i %.9P %.20j %.2t %.10M %.6D %R" # 自定义列 squeue -j 12345 -s # 看该作业的作业步 squeue -i 5 # 每 5 秒刷新ST列的取值：PD排队、R运行、CG完成中、CD已完成、CA已取消、F失败、TO超时、NF节点失效。看到F和TO就该去看sacct的退出码了。
REASON列常见值和处理方向：
| REASON | 含义 | 处置 |
|---|---|---|
Resources | 资源暂不可用 | 正常排队，或用sinfo看目标队列是否全忙 |
Priority | 有更高优先级作业在前 | 换队列或错峰 |
Dependency | 等待依赖作业结束 | 检查--dependency是否写错作业号 |
PartitionNodeLimit | 请求节点数超队列上限 | 减少-N或换队列 |
PartitionTimeLimit | 请求时间超队列上限 | 缩短--time |
QOSMaxJobsPerUser | 该 QOS 下并发作业数超限 | 等前序作业结束，或换 QOS |
ReqNodeNotAvail | 指定节点不可用 | 去掉--nodelist重试 |
BeginTime | 未到--begin指定时间 | 正常等待 |
AssocMaxJobsLimit | 账户级作业数限额 | 合并作业或申请调额 |
把这张表存下来，比在群里问「我的作业为什么不动」效率高得多。
4.3 scontrol show：单个对象的全量细节
squeue给的是摘要，scontrol show给的是一切。
scontrol show partition CPU-Large # 队列配置：时间上限、节点、优先级、允许的 QOS scontrol show node cnode001 # 节点详情：CPUAlloc/CPUTot、RealMemory、State、Reason scontrol show job 12345 # 作业详情：完整参数回显 + 运行状态 scontrol show job 12345 -o # 全部压到一行，方便 grep作业卡住时我一般按这个顺序看：scontrol show job里的JobState、Reason、NodeList，再看scontrol show node <节点>的CPUAlloc/CPUTot和AllocMem/RealMemory。如果节点显示还有空闲核但你的作业排不上，多半是内存或 GPU 卡住了——CPU 有空位不等于资源可满足。
-o那个单行模式特别适合脚本化：scontrol show job 12345 -o | tr ' ' '\n' | grep NodeList能把节点列表单独抠出来。
4.4 sacct 与 speek：作业跑完之后去哪看
作业一从squeue消失，就得靠记账命令。
# 按作业号查历史，重点看 State、ExitCode、MaxRSS sacct -j 12345 --format=JobID,JobName,Partition,State,ExitCode,Elapsed,MaxRSS,NNodes,NTasks # 按时间范围和用户查，适合做周报或排查「昨天那批全挂了」 sacct -S 2020-06-01 -u $USER --format=JobID,JobName,State,Elapsed,ExitCodeExitCode和State组合着看：State=OUT_OF_MEMORY或者ExitCode=0:137基本就是被 OOM killer 干掉了，MaxRSS那列会告诉你实际峰值内存，拿去调--mem就有依据。State=TIMEOUT说明--time给少了，看Elapsed差多少再往上加二成。
关于看屏幕输出，这套集群里有个speek命令能直接看作业的标准输出，但必须说清楚：它是手册作者自己写的封装脚本，不是 Slurm 官方命令，换个集群多半没有。在别处请用tail -f <作业输出文件>，或者按第 2 章的做法把--output写到固定路径。把非官方命令当成通用能力去写进自动化脚本，是最容易在外面跑不起来的一类坑。
5. 排查现场：五类最常见的翻车与对症处置
下面五条都是从「现象」倒推「原因」的路径。前三条属于提交方式错误，后两条属于参数和环境问题，故障率最高。
5.1 现象：登录节点上程序跑着跑着没了，或者同组人集体卡顿
原因：集群的登录节点只用于编译和提交，不承担计算。你在上面跑重负载，要么被系统的进程限制清掉，要么把共享的登录节点 IO 和内存吃满，影响所有人。
解决：任何计算都走sbatch、srun、salloc。只有编译（make、gcc）和短时间的文件操作可以留在登录节点。养成习惯：登录节点上出现time ./app这种命令，立刻改成srun包一层。
5.2 现象：作业状态变成OUT_OF_MEMORY，或者ExitCode是0:137
原因：没写--mem或--mem-per-cpu，调度器按队列默认值分配，比如默认每核 1G，你的程序峰值要 30G，跑到中途就被内核杀掉。137 = 128 + 9，即 SIGKILL。
解决：先用sacct --format=JobID,MaxRSS,State查同类作业的历史峰值，再按峰值上浮 20% 写--mem。注意--mem是每节点内存、--mem-per-cpu是每核内存，两者只写一个，同时写会以后者为准并可能算出个你没想到的总量。
5.3 现象：MPI 作业启动后进程数暴涨、通信卡死或者报端口占用
原因：在srun外面又套了一层mpirun。srun已经按--ntasks起了 N 个进程，mpirun再在每个进程里起 N 个，变成 N 的平方。
解决：脚本里只保留srun ./app。如果程序本身必须用特定的启动器，那就把srun去掉，改用mpirun并按 Slurm 提供的主机列表手工拼参数——但这条路容易出错，优先选前者。自查方法：日志里搜 MPI 世界大小，和你申请的--ntasks对不上就是套娃了。
5.4 现象：作业显示完成，但输出文件是空的、或者找不到
原因有三类：一是--output用了相对路径，而脚本执行目录是分配到的计算节点上的某个目录，不是你提交时所在目录；二是有缓冲没刷盘，程序被scancel时缓冲区丢了；三是多个作业写同一个文件名，互相覆盖。
解决：--output一律写绝对路径或用%x-%j占位符；程序里加fflush或者作业结束前sync；需要区分运行结果就用$SLURM_JOB_ID拼目录。另外在脚本开头打一行pwd和echo $SLURM_SUBMIT_DIR，出问题时一眼就能看出目录错位。
5.5 现象：作业长时间PD，REASON 各不一样
原因：这其实是五类问题，得按 4.2 节的表对症。最常见的是Resources（目标队列真的满）和QOSMaxJobsPerUser（并发数超限），前者只能等或换队列，后者要把多个小作业合并成一个数组作业。
解决：先squeue -j <id> -o "%R"拿到 REASON，再按表处置。如果 REASON 是PartitionNodeLimit而你确实需要那么多节点，就得换队列或拆分作业——这类限额是运维在队列配置里定死的，脚本层面绕不过去。
6. 进阶三件事：sbcast 搬数据、依赖串流程、以及提交前的自检习惯
第一件是sbcast。共享目录（/home）各节点本来就能看到，不需要搬；但/tmp是各节点本地盘，每个节点一份。大作业读同一个输入文件时，几百个进程同时打共享存储，IO 抖动非常明显。用sbcast把文件推到各节点的/tmp再读，能显著减少共享盘压力：
#SBATCH -N 4 #SBATCH -n 128 # 把输入文件分发到每个分配节点的 /tmp 下 sbcast -f /home/user/data/input.bin /tmp/input.bin # 各进程读本地副本，而不是共享盘 srun ./app /tmp/input.bin注意sbcast是每节点一份，文件很大时首次分发本身就慢，只对「读次数远大于写次数」的输入划算。
第二件是作业依赖，用来串流水线。前处理跑完再跑主计算，主计算跑完再做后处理，靠--dependency表达，不要靠人工等：
# 只有 12345 正常结束（退出码 0）才启动 sbatch --dependency=afterok:12345 post.sh # 常用控制：挂起、恢复、重跑、提优先级 scontrol hold 12345 scontrol release 12345 scontrol requeue 12345 scontrol top 12345requeue会把作业重新排队，注意它不会回滚你已写出的文件，脚本要能容忍重跑。
第三件是我自己的提交前自检，四问走完再按回车：
| 检查项 | 判断依据 |
|---|---|
| 队列名对不对 | sinfo输出里存在，且不是全drained |
| 核数与线程数匹配 | OpenMP 用-c，MPI 用-n，不要混 |
| 内存写没写 | --mem或--mem-per-cpu至少一个 |
| 输出路径唯一 | %x-%j或带作业号的目录 |
从那以后我每次提交长作业前，都强制先跑一个 5 分钟的srun小样把 module、路径、进程数验证一遍再sbatch，宁可多花五分钟排队，也不要半夜被OUT_OF_MEMORY叫醒。希望帮到你。
本文还有配套的精品资源，点击获取
