限制slurm中并行作业数量的效率答案

【问题标题】：efficiency in limiting the number of parallel jobs in slurm限制slurm中并行作业数量的效率
【发布时间】：2019-01-19 22:21:36
【问题描述】：

我的问题基于THIS 问题。

我应该考虑使用--array=0-60000%200 将 slurm 中并行运行的作业数限制为 200 个。在我看来，每次完成一项旧工作时，要花上一分钟的时间来处理一份新工作。考虑到我计划运行的作业数量，我可能会以这种方式浪费大量时间。

我写了一个“最有可能”非常低效的替代方案，包括一个启动作业的脚本，检查队列中的作业数，如果我仍然低于允许的最大作业数，则添加作业，while 我达到了最大并行作业数，休眠5秒，如下：

#!/bin/bash

# iterate procedure $1 times.  $1=60000
for ((i=0;i<=$1;i++))
do
    # wait until any queued process is finished
    q=$(squeue -u myuserName | wc -l) #I don't care about +/-1 lines (e.g. title)
    while [ $q -gt 200 ] #max number of parallel jobs set to 200
    do
        sleep 5
        q=$(squeue -u myuserName | wc -l)
    done
    # run the job with sbatch
    sbatch...  
done

与我之前的方法相比，它似乎做得更好，但是，我想知道这种实施实际上效率有多低？为什么？我是否会损害同一集群上其他用户的调度效率？

谢谢。

【问题讨论】：

标签： performance parallel-processing jobs slurm

【解决方案1】：

SLURM 需要一些时间来处理作业列表并决定下一个要运行的作业，特别是在回填调度程序已就位且队列中有大量作业的情况下。由于您使用作业数组，您不会浪费一分钟来安排作业，SLURM 需要一分钟来决定，对于任何其他用户的任何其他作业，无论有或没有作业数组，它都需要相同的分钟。

通过使用您的方法，您的作业也会失去优先级：每次您的一项作业完成时，您都会启动一个新作业，而该新作业将是队列中的最后一个。此外，SLURM 将不得不管理数百个独立的工作，而不仅仅是一个占您需要的 60000 个的工作。

如果您独自在集群中，可能这两种方法没有太大区别，但如果您的集群已满，您的手动方法会给 SLURM 带来稍高的负载，并且与作业数组近似（因为有了作业数组，一旦数组排在第一位，60000 排在第一位，而每次您的作业完成时排在最后一位）。

【讨论】：