如何用SLURM控制M个任务中始终保持N个运行/分配？

需求明确 #

需要在包含M个任务的批处理文件中，始终保持N个任务处于执行/预留状态，当某个任务结束时自动启动下一个任务，避免一次性请求所有资源。

现有写法的问题 #

你给出的写法并不可行：

#SBATCH --ntasks=5

cd $dir1
srun [OPTIONS] --ntasks=1 $(cat my_sim_command)&
cd $dir2
srun [OPTIONS] --ntasks=1 $(cat my_sim_command)&
...
cd $dir20
srun [OPTIONS] --ntasks=1 $(cat my_sim_command)&
cd ..

原因是：所有带&的srun会被一次性后台提交，SLURM不会自动限制并发数。虽然你用#SBATCH --ntasks=5申请了5个任务槽，但这20个srun会同时争抢资源，后续任务会因资源不足阻塞，无法实现“始终保持5个运行”的效果，甚至出现资源调度混乱。

--ntasks选项的真实用途 #

#SBATCH --ntasks=N是向SLURM申请该作业总共可使用的任务槽数量，它本身不会控制任务的启动节奏，仅划定资源上限。要实现任务自动补位的并发逻辑，需要结合SLURM的任务数组或第三方工具。

两种可行实现方案 #

方案1：SLURM任务数组（推荐，适合同构任务） #

如果每个任务仅目录不同、执行逻辑一致，用任务数组最简洁：

#SBATCH --ntasks=1
#SBATCH --array=1-20%5
# --array=1-20 生成20个任务实例，%5限制同时运行5个

# 通过SLURM_ARRAY_TASK_ID匹配对应目录
target_dir="dir${SLURM_ARRAY_TASK_ID}"
cd "${target_dir}"
srun [OPTIONS] $(cat my_sim_command)
cd ..

• 优势：完全由SLURM调度，无需额外工具，自动实现“完成一个启动下一个”，资源调度精准。

方案2：GNU Parallel + SLURM（适合异构任务） #

如果任务逻辑差异较大，可借助GNU Parallel控制并发：

#SBATCH --ntasks=5

# parallel的--jobs参数限制并发数，与SLURM申请的任务槽数量匹配
parallel --jobs 5 'cd {} && srun [OPTIONS] $(cat my_sim_command) && cd ..' ::: dir1 dir2 dir3 ... dir20

• 优势：灵活适配不同逻辑的任务，通过parallel管控并发节奏，SLURM负责资源分配。

内容的提问来源于stack exchange，提问作者Michele Ancis