Question

所以我有一个sbatch（slurm job scheduler）脚本，我通过3个脚本处理大量数据：foo1.sh，foo2.sh和foo3.sh。

foo1.sh和foo2.sh是独立的，我想同时运行它们。 foo3.sh需要foo1.sh和foo2.sh的输出，所以我正在构建一个依赖项。然后我必须重复30次。

让我们说：

## Resources config
#SBATCH --ntasks=30
#SBATCH --task-per-core=1

for i in {1..30};
do
    srun -n 1 --jobid=foo1_$i ./foo1.sh &
    srun -n 1 --jobid=foo2_$i ./foo2.sh &
    srun -n 1 --jobid=foo3_$i --dependency=afterok:foo1_$1:foo2_$i ./foo3.sh &
done;
wait

想法是你启动foo1_1和foo2_1，但由于foo3_1必须等待其他两个工作完成，我想进入下一次迭代。下一次迭代将启动foo1_2 foo2_2，foo3_2将等待等。

然后，在某些时候，使用srun启动的subjobs的数量将高于--ntasks = 30。会发生什么事？是否会等待上一份工作完成（我正在寻找的行为）？

由于

Answer 1

Slurm将运行30 srun，但是31将等待核心在30核分配中释放。请注意，正确的参数是--ntasks-per-core=1，而不是--tasks-per-core=1

你可以使用salloc而不是sbatch自己测试它以交互方式工作：

$ salloc --ntasks=2 --ntasks-per-core=1
$ srun -n 1 sleep 10 & srun -n 1 sleep 10 & time srun -n 1 echo ok
[1] 2734
[2] 2735
ok
[1]-  Done                    srun -n 1 sleep 10
[2]+  Done                    srun -n 1 sleep 10

real    0m10.201s
user    0m0.072s
sys 0m0.028s

你看到简单的echo需要10秒，因为第三个srun必须等到前两个完成，因为分配只是两个核心。

Answer 2

应该发生的是，如果启动的子任务多于核心或超线程的子任务，那么OS调度算法应该处理任务的优先级。根据您运行的操作系统（即使它们都是基于Unix的），在引擎盖下实现的方式也不同。

但是你的假设是正确的，如果你的内核耗尽，那么你的并行任务在某种意义上必须“等待轮到你”。

如果我运行的是更多的子作业而不是分配的核心数，会发生什么

2 个答案: