Slurm作业调度实战：从salloc调试到sbatch批处理排错

简介：面向国科大超算中心用户的Slurm作业调度系统使用指南，系统讲解超算环境下作业提交、队列查看、节点资源查询与并行任务管理方法，适合刚接触超算平台的科研人员、学生及需要查询命令细节的运维使用者。资源共1个文件，为PDF格式电子手册，压缩包整体约595KB，内容覆盖从基础概念到常用命令的完整知识体系。手册以用户常用命令为主线，先介绍三种工作模式、基本术语与常用参考，再分别展示sinfo、squeue、scontrol等查看队列、节点和作业详细信息的方法，随后重点讲解srun、sbatch、salloc、sbcast、sattach等任务提交与管理命令之间的差异和适用场景；针对串行作业、OpenMP共享内存作业、MPI并行作业和GPU作业均给出具体提交示例，并涵盖IO重定向、多程序运行配置、作业屏幕输出查看等实用细节，便于读者对照实践和排查问题。目前已有3347人学习下载，兼具入门学习与日常速查价值。

1. 这不是一份该被收藏吃灰的PDF：Slurm 使用指南到底在帮你解决什么

拿到超算账号的第一天，管理员大概率会甩给你一份 PDF，文件名就叫slurm-userguide.pdf，内容确实全，但它更像一部字典，而不是一条能直接走通的路。真正上手时会卡在很具体的地方：分区到底选哪个、作业脚本里每一行是什么意思、为什么 squeue 看到的作业永远是 PD、作业跑一半被杀到底是谁的锅。这篇不是把那份 Slurm 作业调度系统使用指南复述一遍，而是把「登录 -> 申请资源 -> 提交作业 -> 排查问题」这整条链路，按完全可以照着敲的方式讲清楚。适合刚拿到超算账号、准备把第一个任务跑起来的同学，也适合已经被排队和 OOM 折磨过、想把时间浪费降到最低的人。

2. Slurm 的基础建模：账户、分区、QOS 与三个必须记住的状态

2.1 分区（Partition）、账户（Account）与 QOS：排队规则背后是三张表

超算平台不是一台大电脑，它是一组节点由 Slurm 统一管理。你向 Slurm 要资源时，它并不直接看哪台机器空着，而是先查三张表：你能进哪个分区（Partition）、费用记在哪个账户（Account）、允许用多久用什么优先级（QOS）。很多刚上手的人以为提交作业只需要写--partition，结果作业一直 PD，原因多半是账户或 QOS 没配对。

先看分区。执行sinfo的输出里，每一行代表一个分区（PARTITION），常见的命名习惯是cpu、gpu、bigmem、debug这类。同一台机器可以同时属于多个分区，所以不要用直觉猜，用sinfo -s看每个分区的节点总数和空闲数更直接。我一般会先跑一次：

sinfo -s

sinfo -s输出的列依次是分区名、可用节点数、状态、空闲节点列表。如果某个分区显示drain，说明节点被管理员设置为维护或故障排除状态，作业不会调度过去，排多久都没用。判断完分区，下一步是确认自己的账户和 QOS 有没有绑定关系：

sacctmgr -p show assoc user=$USER format=Account,Partition,QOS

这条命令会列出你的用户名关联了哪些账户、哪些分区、哪些 QOS。你可能会看到同一个账户对应多条记录，比如一个指向 cpu 分区、一个指向 gpu 分区，这很正常。重点看 QOS 列，比如normal、low、high、debug，它们决定了你的作业优先级和能申请的资源上限。

参数说明：-p是让输出变成用竖线分隔的纯文本，方便看；format=后面可以换列名，比如想同时看 MaxTime 就把MaxTime加进去。如果这条命令返回空，说明当前登录账号没有关联任何账户，常见做法是联系管理员给你加账户，或者看 PDF 里写的默认账户是不是一个固定的项目名。

2.2 查询五件套：sinfo、squeue、sacct、scontrol、sstat 各自的脾气

使用指南里最容易被跳过的章节就是「查询命令」，但实际排查时 80% 的时间都在用它们。这五个工具没有谁替代谁，分工完全不同。

• sinfo：看集群全局状态，分区、节点、空闲情况。
• squeue：看作业队列，正在跑的（R）和排队的（PD）。
• sacct：看已经结束的作业，拿到运行时、内存、CPU 使用率。
• scontrol：看单个作业或节点的详细配置，包括作业被拒的具体原因。
• sstat：看正在运行的作业实时的资源使用率，相当于作业的「心电图」。

逐个说用法。squeue最常用，但默认输出列太少，我习惯加-o自定义格式，把真正关心的字段列出来：

squeue -u $USER -o "%.10i %.9P %.8j %.8u %.2t %.10M %.6D %.20R"

各字段含义：%.10i作业 ID，%.9P分区名，%.8j作业名字，%.2t状态（PD/R），%.10M已运行时长，%.6D使用的节点数，%.20R是 Reason，也就是作业在等什么或在哪个节点上跑。R列的.20控制显示宽度，防止长节点名把行撑乱。Reason是重点，如果显示Resources，说明有资源但轮不到你，通常是竞争；显示Priority说明别的同学作业优先级更高；显示AssocGrpCPUMinutesLimit说明账户额度用完了，换分区也没用。

作业结束了怎么办？squeue查不到，用sacct：

sacct -j 123456 --format=JobID,JobName,State,ExitCode,Elapsed,MaxRSS,AllocCPUS,ReqMem

ExitCode里只有第一个数字为 0 才算正常结束；MaxRSS是作业运行过程中用到的最大物理内存，单位是 K/M/G，和ReqMem对比就能看出内存申请是不是太小导致被杀了。看正在运行的作业用sstat：

sstat -j 123456 --format=JobID,MaxRSS,MaxVMSize,AveCPU

注意sstat对已结束的作业无效，它会直接报错或返回空。对已结束作业想复盘，只能走sacct。

2.3 登录节点不是给你算题用的：为什么 PDF 第一页就写「不要跑大任务」

超算平台的节点分两类：登录节点（login node）和计算节点（compute node）。登录节点只有几十个，但所有用户都挤在上面敲命令、编译代码、传文件；计算节点有几百个，才是真正跑任务的地方。Slurm 不会限制你在登录节点上执行任何命令，但管理员会写脚本监控 CPU 和内存：持续跑满超过阈值，进程就会被自动杀掉，甚至可能限制账号登录。

这不是玄学，是资源公平性的问题。你登录节点上python train.py占满 32 核，别人想vim改个文件都会卡。

正确做法：交互式的调试、编译、小数据测试可以在登录节点做，但任何超过 5 分钟的重活，都丢给 Slurm。一个很好用的判断标准是——top里你的进程 CPU 时间超过 30 秒，就该考虑用salloc进计算节点了。后面章节会具体讲salloc和sbatch的使用，这里只需要记住一个原则：登录节点只做「准备」和「收尾」，计算节点的资源才是给你算的。

3. 交互式与批处理作业：salloc、sbatch 与 srun 的正确打开方式

3.1 salloc 交互式作业：调试代码时最顺手的第一站

sbatch适合把任务写好交给调度器去排队运行，但调试阶段你大概率不知道脚本哪里会报错，这时候用salloc最合适。它会先向 Slurm 申请资源，申请成功后你会进入计算节点的一个 shell，之后你敲的每条命令都在计算节点上执行，能直观看到环境变量、目录权限、依赖库是不是正常。

salloc --partition=cpu --account=your_account --qos=normal --time=01:00:00 --nodes=1 --ntasks=1 --cpus-per-task=4 --mem=8G

参数说明：--partition指定分区，和前面sacctmgr查到的记录保持一致；--account是你项目名的账户；--time是最长占用时间，格式HH:MM:SS，超时会被强制结束；--nodes和--ntasks分别代表节点数和任务数；--cpus-per-task是每个任务分配多少核，如果你的代码是 OpenMP 或 Python 多进程，这个值要实际写到程序里，否则申请了 4 核但程序只用 1 核，白白浪费 3 核的资源配额；--mem是总内存，超过会触发 OOM。

进入交互节点后，验证一下你现在在哪台机器上：

hostname

输出应该和登录节点的名字不同。此时squeue -u $USER里你的作业显示为 R，St 是RUNNING。调试结束后，一定要输入exit退出，否则作业会一直占着资源直到超时，白白浪费账户额度。

这里有个常见误区：salloc申请的 shell 本身不执行你的计算程序，它只是给你一个 shell。你需要在这个 shell 里手动敲python train.py之类的命令启动任务，任务结束后再exit。如果你希望任务一申请到资源就立即自动运行，那应该用sbatch，而不是salloc。

3.2 sbatch 批处理作业：从模板到提交的一步到位

批处理是超算最常用的作业方式。你写一个脚本，提交给 Slurm 后它就进入队列，等到资源空闲自动执行，全程不需要你守着。下面这份是经过多次调整后在我这边平台稳定的最小模板：

#!/bin/bash #SBATCH --partition=cpu #SBATCH --account=your_account #SBATCH --qos=normal #SBATCH --job-name=test_job #SBATCH --time=02:00:00 #SBATCH --nodes=1 #SBATCH --ntasks=1 #SBATCH --cpus-per-task=8 #SBATCH --mem=16G #SBATCH --output=job_%j.out #SBATCH --error=job_%j.err module load anaconda/2023.03 source activate my_env cd /path/to/your/project python train.py --config config.yaml

提交命令非常简单：

sbatch run_train.sh

脚本里的#SBATCH是 Slurm 伪指令，不用export，不用srun，直接在sbatch提交时解析。每行的含义：--job-name是作业名字，会显示在 squeue 里，建议写成项目代号方便辨认；--output和--error指定了标准输出和错误日志的路径，%j会自动替换为作业 ID，这样每次提交的日志不会互相覆盖。

参数说明里容易被忽略的是--ntasks和--cpus-per-task的关系。如果你的程序是单进程多线程，保持--ntasks=1，把线程数写在--cpus-per-task，同时要在程序内部显式设置线程数，比如 Python 里torch.set_num_threads(8)。如果你忘了设置，PyTorch 会默认占满节点所有 CPU，这会导致同节点上其他用户的任务性能暴跌，还可能被管理员警告。

还有一个很多人一开始会写错的点：脚本里的cd是必须的。sbatch执行脚本时，工作目录默认是提交命令所在目录，但某些平台配置了--chdir强制行为，所以最好在脚本里显式cd到项目目录，避免出现「明明文件就在当前目录但 python 说找不到」这种诡异问题。

3.3 srun 与 salloc/sbatch 的关系：最容易用错的一个三兄弟

srun的定位是「在已分配的资源里启动任务」。它既可以单独使用（此时会隐式申请资源），也可以在sbatch或salloc分配的作业区域内使用。但很多人会把srun和sbatch混用，造成资源加倍申请。

举一个错误的例子：在sbatch脚本里，#SBATCH已经申请了--ntasks=1 --cpus-per-task=8，你又写srun python train.py，此时srun会尝试重新分配资源，最终可能出现两个任务实例同时运行，或者报srun: Job step creation temporarily disabled的错误。

正确做法分两种情况：

• 脚本里只有简单的单机任务（比如上面那个模板），直接python train.py，不加srun。
• 脚本里是 MPI 多节点任务，才在脚本里写srun ./your_mpi_program。

sbatch分配资源，srun在分配好的资源内部启动并行任务，两条线职责不同。判断你是否需要srun的标准：你的程序是否用到了MPI_Init或分布式通信，如果只用到了多线程，不需要srun。

3.4 作业脚本的 8 个必调参数速查表

4. 软件环境、GPU 申请与多节点作业：从单机到并行

4.1 module load：为什么你的 python 命令报 command not found

超算中心的系统是多人共用的，管理员不会把软件直接装到系统路径里，而是通过环境模块（Environment Modules）来管理。你打开终端直接敲python，大概率报command not found，这不是因为你没装 Python，而是因为 Python 所在的模块还没加载。

使用指南里模块系统通常放在「软件环境」这一节，但很多人忽略了一个关键点：模块加载只对当前 shell 生效。你在登录节点module load anaconda之后，再通过sbatch提交作业，作业脚本里并不会继承这个模块环境，因为sbatch是非交互式运行，环境变量不会传递。

所以要在作业脚本里加一行：

module load anaconda/2023.03

这行必须放在你的程序命令之前。如果你不确定模块名是什么，先查：

module avail

输出列表里会有已有的模块名，注意版本号。不同平台命名可能不同，有的是anaconda3/2023.03，有的是python/3.11。建议选定一个版本后就固定下来，别每次看心情换，版本不一致可能导致 Python 包冲突到怀疑人生。

另一个常见问题是module load的时机。你写进.bashrc里，确实能让每次登录自动加载，但sbatch作业默认不会读取.bashrc，因为非交互 shell 不会 source 它。如果你发现作业脚本里加了module load仍然找不到命令，先确认这一行是不是在脚本的最开头，有没有被set -e提前中断，以及模块系统是不是Lmod——Lmod的module load会做依赖检查，报错信息会直接提示你缺什么。

4.2 GPU 作业申请：--gres=gpu:1 的正确写法与常见坑

GPU 申请比 CPU 多一个维度：你要申请几张卡、要什么型号、要不要同时申请 CPU 和内存配套。不同平台的 GPU 资源命名不一致，有的叫--gres=gpu:1，有的必须写成--gres=rtx3090:1来指定具体型号。

先查出这个平台提供哪些 GPU：

scontrol show node node001 | grep -i gres

观察输出里GRES=字段，找到了就照抄。下面是一个带 GPU 的完整作业脚本：

#!/bin/bash #SBATCH --partition=gpu #SBATCH --account=your_account ##SBATCH --qos=gpu_qos #SBATCH --gres=gpu:1 #SBATCH --nodes=1 #SBATCH --ntasks=1 #SBATCH --cpus-per-task=8 #SBATCH --mem=32G #SBATCH --time=12:00:00 source activate pytorch_env python train.py --gpu-id 0

参数说明：--gres=gpu:1指的是申请 1 张 GPU 卡（这里反爬了你给的:1可以理解为数量），如果你的程序依赖多卡，可以改成gpu:2，但要注意你账户的 QOS 是不是允许一次申请多卡。--partition=gpu和--qos=gpu_qos常见是配套的，如果分区的 QOS 设定不同，提交时就会报错。

提交后怎么确认你的作业真的拿到了 GPU？在作业运行期间，用srun到节点上看：

srun --jobid=123456 nvidia-smi

如果不输出 GPU 信息或显示No devices found，说明你的环境变量CUDA_VISIBLE_DEVICES没有自动设置，或者程序里写死了cuda:0，但实际被分配的是物理卡 2。此时要用 Slurm 提供的环境变量来索引卡：程序里读取CUDA_VISIBLE_DEVICES，在 Python 中直接torch.cuda.set_device(0)即可，因为 Slurm 已经帮你隔离好了。

4.3 多节点 MPI 作业：核心数与分布如何不浪费

多节点作业是超算和普通服务器的最大区别。它让你把任务拆到多台机器上并行，但代价是网络通信和同步开销。新手最容易犯的错误是：申请了 2 个节点，每个节点 32 核，但程序只用了 1 个进程，剩下 63 个核空转。这不叫「预留扩展空间」，这叫浪费配额。

一个合理的多节点作业脚本是这样的：

#!/bin/bash #SBATCH --partition=cpu ##SBATCH --nodes=2 #SBATCH --ntasks-per-node=32 #SBATCH --cpus-per-task=1 #SBATCH --time=04:00:00 module load mpi/openmpi srun ./your_mpi_app

参数说明：--nodes=2是节点数；--ntasks-per-node=32是每个节点上跑 32 个进程，所以总进程数是2*32=64；--cpus-per-task=1表示每个进程只分 1 个核，这种情况适用于 MPI 全程没有 OpenMP 线程的场景。srun ./your_mpi_app会在所有已分配节点上启动对应的进程数。

这里最艰难的决策是--ntasks-per-node别拍脑袋写满。如果节点是 32 核，但你的程序是通信密集型，写成 32 反而会因为 CPU 竞争导致通信变慢。我一般先用小规模跑一次，比如--nodes=2 --ntasks-per-node=16，然后看sacct里的CPU Efficiency指标，如果低于 70%，再决定是否加大进程数。

5. 使用指南没写明白的 5 个坑：排队、被杀与资源浪费

5.1 作业一直是 PD：Reason 显示 Resources 和 Priority 怎么处理

现象：squeue -u $USER看到作业状态是 PD，Reason 写Resources或Priority，等了一天也不动。

先说Resources。它表示你要的资源当前不满足，比如你要 64 核，但所有 CPU 分区的空闲核心加起来都不够。查看方法是sinfo的空闲核数。处理办法：换一个更空闲的分区，或者减少--time（有些平台会把短作业优先级提高）。如果你只是测试脚本，可以试着改成--time=00:30:00，短作业往往更容易被调度进去。

Priority则表示有比你优先级高的作业在排。不要死等，去看同分区是不是有别人提交了更大规模或更长时间的作业，如果 QOS 里有high但你没用上，检查你是否有权限使用：

sacctmgr -p show qos format=Name,Priority,MaxTime,MaxNodes

注意：如果角色是普通用户，没有管理员权限，不要试图修改 QOS 属性，那只会浪费你更多时间。

5.2 作业跑一半被杀：TIME LIMIT 还是 OOM

现象：作业日志里出现类似slurmstepd: error: *** JOB 123456 ON node001 CANCELLED AT 2025-xx-xxT12:00 DUE TO TIME LIMIT ***，或者 OOM。

TIME LIMIT最直接，就是--time写短了。先看作业跑了多久被杀的，再估算任务还需要多少时间，把--time加 30% 的余量重新提交。

OOM 则要区分是哪个进程被杀了。如果日志只有Killed没有OOM字样，用sacct -j 作业ID --format=JobID,MaxRSS,ReqMem查看实际内存峰值和申请内存对比。MaxRSS > ReqMem就说明内存参数设置小了。把--mem调大的同时，也要在程序里检查是不是有数据缓存泄漏。如果是 Python 程序，优先排查是否加载了超大数据文件进内存且没有释放。

5.3 GPU 明明空闲但你申请不到

现象：nvidia-smi看到某节点 GPU 显存占用只有 20%，但你提交--gres=gpu:1的作业还是 PD。

原因：GPU 资源粒度默认按「卡」分配。只要一张卡被某个作业占用（哪怕只用了 1GB 显存），该卡就会被标记为 allocated，你的作业就不能用。很多同学的显存占用不高，但整卡被占满的情况在共享平台上很常见。

解决：看scontrol show node 节点名里的Gres和AllocGres字段，确认是整卡粒度。如果是整卡粒度，只能等，或者换节点。另外不要在作业里用nvidia-smi里的空闲显存来判断能不能用，那个数值对调度器来说没有意义。

5.4 module load 之后命令还是找不到

现象：登录节点手动module load某个软件后能正常运行，但写进sbatch脚本里提交，作业日志报command not found。

原因有三个分支：第一，module命令在非交互 shell 里没有初始化，这种情况在脚本第一行显式加载模块系统文件；第二，你加载的软件模块本身需要依赖另一个模块，比如module load cuda需要先module load gcc，单独加载一个带依赖检查失败也会导致命令不可用；第三，软件装在某个非标准路径，module load之后PATH没包含可执行文件目录。

排查顺序：先在登录节点手动执行module load，然后which 你的命令，看路径是否正确；再在作业脚本里把module load放到source activate的前面；最后在脚本里加一行echo $PATH输出环境变量，确认是否真的被修改了。如果路径包含了目标目录但仍报找不到，检查该目录下的文件是否有执行权限：

ls -l $(which 你的命令)

5.5 磁盘配额写满导致作业提交失败

现象：sbatch提交时报错sbatch: error: Batch job submission failed: Socket timed out或直接提示Disk quota exceeded。

原因：用户主目录$HOME通常有配额限制，比如 20GB，而很多人把数据集、模型权重、虚拟环境都装在了 HOME 下。sbatch提交作业的时候，Slurm 会读取一些临时文件，如果磁盘写满，提交直接失败。

处理：先把大数据放到工作目录或共享存储路径下，这个路径在平台的 PDF 里通常有明确说明，一般叫项目空间或 scratch 目录。用du -sh $HOME/*找到占空间的大目录，虚拟环境如果已经在 HOME 下，可以重装到项目目录；然后定期用find $HOME -mtime +30 -size +1G清理旧文件。养成习惯：提交作业前先df -h $HOME看一眼剩余空间。

6. 三个能长期提升效率的进阶习惯：作业数组、作业依赖与 sacct 复盘

6.1 作业数组：把 100 个任务写进一个脚本

如果你的任务是对 100 个不同参数做独立实验，不要手动提交 100 次sbatch，用作业数组一步到位：

#!/bin/bash ##SBATCH --array=1-100 #SBATCH --partition=cpu #SBATCH --cpus-per-task=4 python train.py --seed $SLURM_ARRAY_TASK_ID --config config_${SLURM_ARRAY_TASK_ID}.yaml

$SLURM_ARRAY_TASK_ID是每个子任务的编号，--array=1-100会生成 100 个独立作业，每个作业拥有自己的任务 ID。这个习惯的好处是调度器可以把它们打散到不同节点上并行执行，比串行提交快得多，而且sacct记录按任务 ID 分组，复盘时一目了然。

6.2 作业依赖：让前后处理自动排队

训练完成后通常要跑评估脚本，手动盯着队列再提交又慢又容易忘。用--dependency让评估作业训练结束后自动启动：

sbatch --dependency=afterok:123456 evaluate.sh

afterok:123456表示作业 123456 成功结束后才允许启动；如果训练失败了，评估作业不会启动。这让整个流程串起来，你只需要盯最终结果，不需要反复登录。

6.3 sacct 复盘：每次跑完必看的三个数字

我个人的习惯是每个作业结束后都跑一次sacct，看三个数字：Elapsed（实际耗时是否和预估一致）、MaxRSS（内存申请是否过剩）、CPU Efficiency（计算核心是否真的被用上）。很多平台的sacct默认不输出效率，需要到sreport或特定配置里找，但至少前三项能帮你发现一半的资源浪费问题。比如有次我自己的代码申请 8 核、--mem=32G，实际MaxRSS只用了 3G，CPU 效率只有 12%。后来意识到是数据加载在 IO 上阻塞了，改成多线程读取数据后，同样资源下效率翻了三倍。

我还吃过大意亏：有次提交前忘了改--time，用上次的 48 小时配置跑一个明明 2 小时就能结束的任务，导致排队优先级下降，白白等了很久。所以现在每次提交前都会亲手重新写一遍时间参数，不让旧脚本的参数悄悄溜进新任务。

超算是个排队的世界，Slurm 的参数就是你和调度器沟通的语言。从salloc调试、sbatch跑批、sacct复盘，再到学会看 Reason、调 QOS、写作业数组，这套链路跑通之后，你在集群上的时间能被压缩至少三分之一。希望这篇能让你少踩几个我踩过的坑，后面真正需要时，再配合那份slurm-userguide.pdf去查具体字段，会顺利很多。

本文还有配套的精品资源，点击获取