当前位置：首页 > news >正文

Slurm作业调度实战：从sbatch到sacct的完整生命周期管理

news 2026/8/1 9:15:15

1. 从“sbatch”到“squeue”：理解Slurm的作业生命周期

如果你刚接触高性能计算（HPC）集群，面对满屏的命令行和陌生的术语，可能会感到无从下手。Slurm（Simple Linux Utility for Resource Management）是目前最主流的开源集群管理和作业调度系统之一，它负责管理集群的计算节点、分配计算资源、排队和执行用户提交的任务。简单来说，它就是你与背后成百上千台计算服务器打交道的“总调度员”。掌握Slurm的常用命令，意味着你拿到了高效使用这些宝贵计算资源的钥匙，能让你从“排队等结果”的被动状态，转变为“精准掌控任务”的主动状态。

很多新手会陷入一个误区：把Slurm命令当作一堆孤立的指令来记忆。实际上，这些命令紧密围绕着作业的生命周期——从创建、提交、排队、运行、监控到最终完成或清理。理解这个生命周期，命令就不再是枯燥的符号，而是一套有逻辑的工具。本文不会仅仅罗列命令手册，而是以一个典型的数据分析作业为例，带你走完从编写脚本到查看结果的完整流程，穿插我这些年踩过的坑和总结出的高效技巧。你会发现，用好Slurm，不仅能跑通任务，更能优化资源使用，节省大量等待时间。

2. 作业的诞生与提交：`sbatch`脚本的编写艺术

提交作业是使用Slurm的第一步，而sbatch命令是这一切的起点。但直接敲sbatch my_script.sh往往只是开始，真正的功夫在脚本本身。一个考虑周全的提交脚本，是作业能否顺利运行的基础。

2.1 理解Slurm指令与Bash脚本的融合

一个Slurm提交脚本本质是一个Bash脚本，只是在开头通过以#SBATCH开头的注释行，向Slurm传递资源请求和作业属性。Slurm会解析这些指令，然后执行脚本中后续的命令。这里最大的坑在于混淆了解析阶段和执行阶段。所有#SBATCH指令必须在任何可执行的Bash命令之前，因为Slurm在脚本开始执行前就读取它们。我曾见过有人把#SBATCH指令放在echo命令之后，结果就是资源请求完全被忽略，作业以默认参数提交，很可能因为资源不足而失败。

一个最小化但功能完整的脚本模板如下：

#!/bin/bash #SBATCH --job-name=my_analysis # 作业名，方便在队列中识别 #SBATCH --output=slurm-%j.out # 标准输出重定向文件，%j会被替换为作业ID #SBATCH --error=slurm-%j.err # 标准错误重定向文件 #SBATCH --partition=compute # 指定提交到的分区（队列） #SBATCH --nodes=1 # 请求的节点数 #SBATCH --ntasks-per-node=4 # 每个节点上启动的任务数（通常理解为CPU核心数） #SBATCH --time=01:00:00 # 作业运行最大时间（时:分:秒） #SBATCH --mem=8G # 每个节点所需内存 # 从这里开始是正常的Bash命令 echo “Starting job at: $(date)” echo “Running on host: $(hostname)” # 加载必要的软件环境（取决于集群的模块系统，如Environment Modules或Lmod） module load python/3.9 module load gcc/11.2 # 执行你的计算程序 python my_data_analysis_script.py --input data.csv --output results/ echo “Job finished at: $(date)”

2.2 关键参数详解与选型逻辑

--job-name：给作业起个有意义的名字。当你有几十个作业在队列里时，“test1”和“cnn_mnist_epoch50”哪个更一目了然？后者能让你用squeue命令快速定位。
--output/--error：强烈建议始终显式指定。默认输出会放在提交作业的目录，但文件名是slurm-<jobid>.out，混杂了标准输出和错误。分开重定向利于调试。%j（作业ID）和%x（作业名）是常用的替换符。一个进阶技巧是：--output=logs/%x-%j.out，将日志统一归入logs目录。
--partition：这是指定作业队列。集群通常设有不同分区，如debug（短时测试，优先级高，时间限制严）、compute（常规计算）、bigmem（大内存节点）、gpu（GPU节点）。选错分区会导致作业排队时间极长或被拒绝。不清楚时，用scontrol show partitions查看所有可用分区及其限制。
--nodes、--ntasks、--cpus-per-task、--ntasks-per-node：这是资源请求的核心，也是最容易出错的地方。你需要根据程序的并行模式来选择：
- OpenMP/多线程程序：使用单节点多核心。推荐--nodes=1 --cpus-per-task=8，表示请求1个节点上的8个CPU核心给一个任务。--cpus-per-task是关键。
- MPI（分布式内存）程序：使用多节点多进程。推荐--nodes=2 --ntasks-per-node=16，表示请求2个节点，每个节点上运行16个MPI进程（共32个进程）。--ntasks是进程总数，也可直接用--ntasks=32，由Slurm分配节点。
- 混合模式（MPI+OpenMP）：--nodes=2 --ntasks-per-node=4 --cpus-per-task=4，表示2个节点，每个节点4个MPI进程，每个MPI进程配4个OpenMP线程。
- 单核串行程序：--nodes=1 --ntasks=1 --cpus-per-task=1。
- 注意：--ntasks-per-node和--cpus-per-task是互斥的。如果你定义了--cpus-per-task，Slurm会认为你使用OpenMP，并为每个任务分配指定数量的CPU。此时再指定--ntasks-per-node可能会引发冲突。最佳实践是，根据你的并行模型，只设置其中一组参数。
--time：这是影响作业调度优先级和成败的关键参数。Slurm使用回填调度，即会优先运行能“塞进”空闲资源空隙的小作业。如果你预估作业需要2小时，但设置了--time=24:00:00，调度器会认为你需要占用资源24小时，可能一直找不到这么大的连续空闲时间块，导致排队很久。相反，如果你低估了时间（如只设了1小时），作业运行超时后会被系统强制终止（TIMEOUT状态）。我的经验法则是：实际预估时间乘以1.2作为安全缓冲，但不要过度夸大。对于测试作业，尽量使用debug分区并设置较短时间。
--mem：指定每个节点需要的内存总量（如8G）或每个CPU核心的内存（如--mem-per-cpu=2G）。如果作业内存超出申请值，会被Slurm强制杀死（OUT_OF_MEMORY状态）。监控首次运行的实际内存使用量（用sacct查看，后文详述），以此为基础增加20-30%作为后续请求值。

2.3 提交作业与立即反馈

编写好脚本（假设名为submit.sh）后，使用sbatch submit.sh提交。提交成功后，命令行会立即返回一个作业ID，例如Submitted batch job 1234567。请务必记下这个ID，它是后续监控、管理作业的唯一凭证。

如果提交失败，常见原因和排查命令如下：

无效参数：sbatch会直接报错，如error: Invalid partition name specified。仔细检查参数拼写和值。
超出限制：如请求的内存或时间超过该分区或你账户的限制。使用sacctmgr show assoc user=$USER查看自己的账户关联和限制。
脚本语法错误：虽然sbatch提交时不会检查Bash语法，但作业开始执行时一旦出错会迅速失败。可以用bash -n submit.sh预先检查脚本语法。

3. 队列中的守望：使用`squeue`与`scontrol`监控作业状态

作业提交后，便进入了调度队列。了解作业的实时状态是日常操作。

3.1`squeue`：查看队列全景与个人作业

最常用的命令是squeue，它会列出队列中所有作业。但直接使用信息量巨大。你需要掌握几个关键过滤和格式化选项：

只看自己的作业：squeue -u $USER或squeue --user=$USER。这是每天使用频率最高的命令。
查看特定作业：squeue -j 1234567。
格式化输出：默认输出可能很宽。我喜欢自定义格式：squeue -u $USER -o “%.18i %.12P %.40j %.8u %.8T %.10M %.6D %.4C %.10m %R”。这里：
- %i: 作业ID
- %P: 分区
- %j: 作业名
- %u: 用户
- %T: 状态（最重要）
- %M: 运行时间
- %D: 节点数
- %C: CPU核心数
- %m: 内存（请求）
- %R: 运行节点列表（短）你可以把这个长命令设为别名，比如在~/.bashrc中加入：alias myq=‘squeue -u $USER -o “%.18i %.12P %.40j %.8u %.8T %.10M %.6D %.4C %.10m %R”’。
理解作业状态（ST字段）：
- PD(Pending): 作业在排队，等待资源。这是最常见状态。
- R(Running): 作业正在运行。
- CG(Completing): 作业已完成，正在做收尾工作（如清理临时文件）。
- F(Failed): 作业失败。需要查看错误日志（.err文件）。
- TO(Timeout): 作业超时被终止。需要增加--time参数或优化程序。
- OOM(Out Of Memory): 内存不足被杀死。需要增加--mem请求。
- CA(Cancelled): 作业被取消。

3.2`scontrol`：获取作业的详细信息与控制

squeue提供概览，而scontrol show job <jobid>则能提供关于一个作业的海量详细信息，包括：

详细的资源请求（CPU、内存、节点列表、时间限制）。
作业的实际使用资源（如果已在运行）。
作业的提交时间、开始时间、预计结束时间。
作业的退出码（如果已结束）。
作业的工作目录、提交脚本路径。

当作业状态异常（如长时间PD，或突然F）时，scontrol是首要诊断工具。例如，scontrol show job 1234567 | grep -E “Reason|WorkDir|StdOut|StdErr”可以快速抓取失败原因、日志路径等关键信息。

scontrol还可以用于修改排队中（PD状态）的作业参数，而无需取消重提，这是一个非常省时的功能。例如，你发现作业请求的内存太大导致没有合适节点，可以：scontrol update jobid=1234567 mem=4G。可以修改的参数包括--time,--mem,--partition等。但注意，无法修改已经运行（R状态）作业的资源请求。

3.3 动态跟踪输出：`tail -f`与`watch`结合

对于运行中的作业，你想实时查看其输出日志，可以使用tail -f slurm-1234567.out。如果作业输出不多，这很有效。但对于长时间运行的任务，更高效的方式是结合watch命令定期检查状态：watch -n 10 ‘squeue -u $USER’（每10秒刷新一次队列状态）。或者，你可以写一个简单的监控脚本，同时显示状态和日志尾部。

4. 作业的干预与终止：`scancel`的精准操作

当你需要停止一个作业时，scancel是你的工具。但粗暴地scancel <jobid>可能带来问题，比如程序正在写文件，突然终止可能导致数据损坏。

4.1 优雅终止与强制终止

默认终止：scancel 1234567。这会向作业发送一个终止信号（SIGTERM），允许程序进行清理工作。大多数程序会捕获这个信号，保存当前状态后退出。
强制立即终止：scancel -9 1234567或scancel --signal=9 1234567。发送SIGKILL信号，作业立即被杀死，没有清理机会。仅在程序无响应时使用。
终止用户所有作业：scancel -u $USER。慎用！特别是在共享集群上，可能会误杀他人的作业（需要管理员权限才能终止他人作业）。通常用scancel -u $USER --state=PENDING只取消所有排队中的作业。

4.2 基于条件的批量取消

这是scancel的高级用法，能极大提升效率。例如：

取消所有在debug分区的作业：scancel -p debug -u $USER
取消所有作业名包含“test”的作业：scancel --name=*test* -u $USER（注意通配符可能需要引号）
取消所有状态为PENDING且运行时间请求超过1天的作业：scancel -t PENDING --time-min=1-00:00:00 -u $USER

在运行大规模参数扫描时，我经常提交数百个作业。如果发现某个参数设置有误，用一条条件式scancel命令就能批量清理错误提交的作业，避免逐个查找ID。

5. 事后的复盘：用`sacct`进行作业会计与性能分析

作业结束后，squeue就看不到了。这时sacct（Slurm accounting）命令闪亮登场。它从会计数据库里查询历史作业信息，是分析作业表现、排查问题、统计资源使用的利器。

5.1 基础查询：查看作业结局与资源使用

sacct -j 1234567：查看指定作业的会计信息。默认显示作业步（JobStep）信息，如批处理步（batch）和内部任务步。
sacct -j 1234567 -o JobID,JobName,Partition,Account,AllocCPUS,ReqMem,Elapsed,State,ExitCode,MaxRSS：这是我常用的格式化输出。
- MaxRSS：实际最大常驻内存集。这是调整--mem参数最重要的依据。对比ReqMem（请求内存）和MaxRSS，如果MaxRSS接近但未超过ReqMem，说明内存请求恰到好处；如果远小于ReqMem，说明请求过多，浪费了资源，下次可以减少；如果MaxRSS缺失或为0，可能是作业太快或监控未开启，对于长时间作业这个值很可靠。
- Elapsed：实际运行时间。对比--time请求，优化时间预估。
- ExitCode：退出状态。0:0通常表示成功。非零值表示程序自身错误，需要结合.err日志文件排查。
- AllocCPUS：实际分配的CPU数。

5.2 高级查询与批量分析

sacct的强大在于其丰富的过滤和格式化选项，能生成资源使用报告。

查看最近一天自己所有作业的摘要：

sacct -u $USER -S $(date -d “yesterday” +%Y-%m-%d) -o JobID,JobName,Partition,AllocCPUS,ReqMem,MaxRSS,Elapsed,State

统计某个项目（通过作业名筛选）的总CPU小时消耗：
```
sacct -u $USER -X -n -o CPUTimeRAW --name=project_*
```
然后可以用管道传递给awk求和：sacct ... | awk ‘{sum+=$1} END {print sum/3600 “ CPU-Hours”}’。这对向导师或项目组汇报资源使用量非常有用。
查找所有因内存不足（OOM）而失败的作业：
```
sacct -u $USER -S 2024-01-01 -o JobID,JobName,ReqMem,MaxRSS,State -s F,OOM
```
-s用于过滤状态。

一个重要提示：sacct默认可能只显示最近一天的作业。使用-S（开始时间）和-E（结束时间）选项来指定查询范围。例如-S 2024-05-01。会计数据保留时间由集群管理员设置。

6. 交互式计算与开发：`srun`与`salloc`的灵活运用

除了批处理作业，Slurm也支持交互式运行，这对于调试、开发、数据可视化或运行交互式应用（如Jupyter Notebook, MATLAB GUI）至关重要。

6.1`srun`：直接运行交互式命令

srun命令会分配资源并立即在其上运行一个命令。它类似于sbatch的即时交互版本。

申请一个节点的一个核心，运行一个shell：srun --pty -p debug -N 1 -n 1 --mem=2G -t 01:00:00 /bin/bash。这会分配资源并启动一个Bash shell。退出shell，资源即释放。
在GPU节点上启动一个Jupyter Lab：
```
srun --pty -p gpu -N 1 --gres=gpu:1 --mem=16G -t 04:00:00 jupyter lab --no-browser --ip=0.0.0.0 --port=8888
```
然后根据输出提示，在本地浏览器通过SSH隧道连接。这种方式比在登录节点直接运行Jupyter更规范，不占用登录节点资源。
运行一个简单的并行测试：srun -N 2 -n 4 hostname。这会申请2个节点，共运行4个任务（进程），每个任务执行hostname命令，输出4个主机名，可用于测试MPI环境。

6.2`salloc`：分配一个交互式会话

salloc与srun不同，它先分配资源并返回一个作业ID，然后你可以在当前shell中使用srun命令将任务提交到这个分配的资源集上。这为你提供了一个“交互式作业”环境。

# 第一步：分配资源 $ salloc -p compute -N 1 -n 8 --mem=16G -t 02:00:00 salloc: Granted job allocation 1234580 salloc: Waiting for resource configuration salloc: Nodes node-001 are ready for job # 此时，你的终端已经“附着”到了这个分配上。环境变量`SLURM_JOB_ID`等已被设置。 # 第二步：在分配的资源上运行任务 $ srun hostname # 这会使用分配的资源（8个核心）运行命令 node-001 ... # 你可以多次使用 srun $ srun ./my_mpi_program # 第三步：释放资源 $ exit # 或者按 Ctrl+D salloc: Relinquishing job allocation 1234580

salloc+srun的模式非常适合需要多次运行不同命令的交互式开发调试阶段。而srun --pty则适合单次、长时间的交互会话。

6.3 交互式使用的注意事项

资源释放：无论是srun --pty启动的shell还是salloc分配的会话，务必记得退出（输入exit或Ctrl+D）。否则资源会一直被占用，直到时间限额用完，影响他人使用，也可能导致你的账户被限制。
使用debug分区：交互式任务通常时间短、需求明确，应优先提交到debug分区，排队快，且避免占用长时间计算资源。
终端断开：如果SSH连接断开，交互式作业可能会被终止。可以使用screen或tmux这类终端复用器，在srun或salloc前启动它们，确保会话持久化。

7. 集群信息查询：知己知彼，百战不殆

高效调度作业，需要对集群状态有清晰了解。Slurm提供了一系列信息查询命令。

sinfo：查看分区和节点状态
- sinfo：概要查看所有分区状态。
- sinfo -s：按分区汇总节点状态。
- sinfo -N -o “%N %P %c %m %G %t”：以自定义格式列出所有节点信息，包括节点名、分区、CPU数、内存、GPU资源、状态。%G字段可以显示GPU信息（如gpu:tesla:2）。
- 关键节点状态：
  - idle：空闲，可用。
  - alloc：已分配，正在使用。
  - mix：部分占用，仍有空闲资源。
  - drain：排水/维护状态，不可用。
  - down：故障，不可用。看到想用的分区节点全是alloc或drain，就知道为什么作业在排队了。
scontrol show node <nodename>：查看特定节点的详细信息，包括硬件配置、当前运行的作业、实时负载等。当你怀疑某个节点有问题时（比如作业总在上面失败），可以用这个命令深入检查。
sprio：查看作业优先级构成（如果集群配置了优先级插件）。作业优先级决定了在PD队列中的排序。sprio -u $USER可以查看自己作业的优先级分数及其构成（如等待时间、作业大小、用户公平份额等），帮助你理解为什么别人的作业排在你前面。

8. 实战中的组合拳与避坑指南

掌握了单个命令，就像拥有了散落的工具。真正的效率来自于将它们组合起来，形成工作流，并避开常见的陷阱。

8.1 高效工作流示例：参数扫描与结果收集

假设你需要用不同的参数运行同一个Python脚本100次。手动写100个提交脚本是不可接受的。

方案一：使用Bash循环与sbatch

#!/bin/bash for seed in {1..100}; do sbatch << EOF #!/bin/bash #SBATCH --job-name=scan_${seed} #SBATCH --output=logs/scan_${seed}.out #SBATCH --error=logs/scan_${seed}.err #SBATCH --partition=compute #SBATCH --ntasks=1 #SBATCH --time=00:30:00 #SBATCH --mem=2G python my_simulation.py --seed ${seed} --output result_${seed}.csv EOF done

这里使用了Here Document（<< EOF ... EOF）来动态生成并提交作业脚本。所有作业会同时进入队列。你需要确保集群能承受100个作业的并发调度压力，或者使用--array（见下文）是更好的选择。

方案二：使用作业数组（Job Array）—— 更优雅的方式Slurm的作业数组功能可以提交一组高度相似的任务，它们共享相同的资源请求和脚本，仅通过一个环境变量$SLURM_ARRAY_TASK_ID来区分。

#!/bin/bash #SBATCH --job-name=param_scan #SBATCH --output=logs/scan_%A_%a.out # %A 是数组作业的主ID，%a 是数组索引 #SBATCH --error=logs/scan_%A_%a.err #SBATCH --partition=compute #SBATCH --ntasks=1 #SBATCH --time=00:30:00 #SBATCH --mem=2G #SBATCH --array=1-100 # 关键！定义数组索引从1到100 # 使用数组索引作为参数 SEED=$SLURM_ARRAY_TASK_ID python my_simulation.py --seed ${SEED} --output result_${SEED}.csv

只需提交一次：sbatch array_job.sh。Slurm会创建一个包含100个子任务的作业数组。你可以用squeue看到它们（作业名后会显示_[1-100]）。管理起来非常方便：

取消整个数组：scancel 1234600（主作业ID）。
取消特定索引任务：scancel 1234600_50。
查看数组任务状态：squeue -u $USER --array或sacct -j 1234600 --array。

作业数组是进行参数扫描、交叉验证等任务的最佳实践，对调度系统更友好，管理也更集中。

8.2 常见“坑”与应对策略

坑：作业一直Pending (PD)，sinfo显示节点idle。
- 排查：首先用scontrol show job <jobid>查看Reason字段。常见原因：
  - Resources：请求的资源（如特定节点特征、GPU类型）暂时无法满足。
  - Priority：优先级不够高，前面有更多/更优先的作业。
  - QOSMaxCpuPerUserLimit：达到了服务质量（QoS）的CPU使用上限。用sacctmgr show qos和sacctmgr show assoc user=$USER查看限制。
  - PartitionTimeLimit：作业请求时间超过分区最大限制。
- 应对：根据原因调整请求，或联系管理员。
坑：作业运行几分钟后失败，退出码为137 (SIGKILL)。
- 排查：这通常是资源超限被系统杀死。首先检查sacct输出的State和MaxRSS。
  - 如果State是OOM，则是内存超限。
  - 如果State是TIMEOUT，则是运行时间超限。
  - 也可能是节点故障，但较罕见。
- 应对：增加--mem或--time参数。对于内存，建议基于历史成功作业的MaxRSS上浮20-30%申请。
坑：.out日志文件为空或很小，但作业失败了。
- 排查：程序错误通常输出到标准错误（stderr）。一定要同时检查.err文件。在提交脚本中，将标准错误重定向到单独文件是好习惯。另外，有些程序的输出可能被缓冲了，没有及时写入文件。可以在Python脚本中设置flush=True，或在C/C++程序里手动刷新缓冲区。
坑：MPI作业卡住，或者报错“找不到主机”。
- 排查：确保你的sbatch参数与MPI启动方式匹配。Slurm通常与mpirun、srun配合工作。现代HPC集群推荐使用srun来启动MPI程序，因为srun能直接理解Slurm分配的资源拓扑。示例脚本：
```
#SBATCH --nodes=2 #SBATCH --ntasks-per-node=16 module load openmpi srun ./my_mpi_program # 使用 srun 而不是 mpirun
```
- 应对：查阅集群文档，确认推荐的MPI启动命令。运行前用srun hostname测试MPI环境是否正常。
坑：依赖其他作业完成（工作流依赖）。
- 解决方案：使用--dependency参数。例如，作业B必须在作业A成功完成后才能开始：sbatch --dependency=afterok:1234500 job_b.sh。依赖类型还有：
  - afterany:<jobid>：作业A结束后（无论成功失败）开始B。
  - afternotok:<jobid>：作业A失败后开始B。
  - singleton：同一时间只能有一个同名作业在运行（用于防止重复提交）。这对于构建多阶段数据处理流水线非常有用。