我正在以口吃的方式运行一组许多并行作业（大约1000个），并且每个作业都必须分配给一个CPU。阅读slurm documentation后，我发现了这一点：
最佳做法，大量工作
考虑将相关工作纳入 由于性能原因，单个Slurm作业具有多个作业步骤 和易于管理。每个Slurm作业可以包含多个作业 步骤，Slurm中用于管理工作步骤的开销要低得多 比个人工作要多。
作业数组是管理以下内容的集合的有效机制 具有相同资源需求的批处理作业。大多数Slurm命令 可以将作业数组作为单独的元素（任务）或作为 单个实体（例如，在单个命令中删除整个作业数组）。
这似乎意味着具有多个作业步骤的单个作业（例如，具有多个srun调用的批处理脚本，每个脚本具有相同的资源）比作业数组的性能更好。不过，我的问题是我不想阻塞其他人的资源。如果我用1000个srun调用运行一个作业，则该作业一旦开始运行，它将不断阻止大量处理器，但是，如果我运行一个包含1000个作业的作业阵列，则这些作业仅在队列中可用时才使用处理器，我认为这更加灵活。
我的问题是：在作业步骤上运行作业阵列的开销是否足以让我担心呢？如果开销很大，还有其他选择吗？人们通常如何应对这种情况？我已经看到人们在某些情况下将GNU与slurm并行使用，它提供任何优势吗？这是可能的用例吗？
答案 0 :(得分：1)
在作业步骤上运行作业阵列的开销是否足以让我担心呢？
这完全取决于一个步骤的持续时间。根据群集的不同，安排和启动作业可能需要花费几十秒钟的时间（准备环境，创建临时目录，进行一些清洁以及可能的状况检查或运行状况检查）。因此，如果一个步骤只花了不到几分钟的时间，那么您肯定需要对其进行“打包”。否则，您花在计算上的时间要比组织计算花费的时间多。
相比之下，如果一个步骤接近群集上允许的最大挂墙时间，则最好使用作业数组。
请注意，您也可以介于两者之间，并提交大小为10的数组，其中包含100个步骤的作业。
如果开销很大，还有其他选择吗？
您可以使用元计划程序和有时称为“滑入式”的技术，在该技术中，您提交的作业除了听工作流组织者向其提供任务外没有其他作用。例如参见FireWorks
人们通常如何应对这种情况？
他们要求系统管理员提供指导，以了解他们希望管理的内容。有时候，做一些小工作可能会增加群集的总利用率，这是很好的选择；有时，做很多小工作会降低调度的性能。
我已经看到人们在某些情况下将GNU与slurm并行使用，这有什么好处吗？
GNU Parallel具有非常强大的工具来生成作业步骤，例如，计算一对参数的所有成对可能值，或对文件进行高级遍历，等等。
它还允许用一行替换Bash的几行来处理所有步骤的开始。
这是可能的用例吗？
是的，您可以使用它，但是它不能帮助您决定主要问题。