slurm作业数组和作业步骤性能的区别

Question

我正在slurm中运行许多并行作业（约1000个），每个作业都必须分配一个CPU。阅读slurm documentation，我发现了以下内容：

最佳实践，大型作业计数

考虑将相关工作放入单个Slurm作业中，其中包含多个作业步骤，以提高性能和管理便利性。每个Slurm作业可以包含多个作业步骤，管理作业步骤的开销比单独作业要小得多。

作业数组是管理具有相同资源要求的批处理作业集合的有效机制。大多数Slurm命令可以将作业数组作为单个实体（例如，删除整个作业数组）或单个元素（任务）进行管理。

这似乎意味着一个包含多个作业步骤的单个作业（例如，一个批处理脚本，其中有许多相同资源的srun调用）比作业数组执行得更好。但我的问题是我不想为其他人阻塞资源；如果我运行一个具有1000个srun调用的作业，一旦它开始运行，该作业将不断地阻塞大量处理器，然而，如果我运行一个包含1000个作业的作业数组，那么这些作业只会在队列上有可用处理器时使用处理器，我认为这更加灵活。

我的问题是：运行作业数组的开销是否足够显著，让我担心这个问题？如果开销很大，是否有任何替代方法？人们通常如何处理这种情况？我已经看到人们在某些情况下使用GNU并行工具和slurm，它提供了什么优势？这是一个可能的用例吗？

- Ignacio

Answer 1

“运行作业数组”与“作业步骤”之间的开销是否足够大，让我需要担心这个问题？这完全取决于一个步骤的持续时间。根据群集、调度和启动作业可能需要几十秒钟（准备环境、创建临时目录、进行一些清理工作，也许还有健全性检查或健康检查）。因此，如果一个步骤少于几分钟，您肯定需要将它们“打包”。否则，您将花费与组织计算相同的时间。

相比之下，如果一个步骤接近群集允许的最大壁钟时间，则最好使用作业数组。

请注意，您还可以在其中提交大小为10的数组，其中作业运行100个步骤。

“如果开销很大，是否有任何替代方案？” 您可以使用元调度程序和称为滑入式的技术，其中您提交一个除了侦听工作流组织者提供任务之外什么都不做的作业。例如，请参见FireWorks

“人们通常如何处理这种情况？”

他们询问系统管理员的指导，以了解他们更喜欢管理什么。有时候有小任务可能会增加集群的总利用率，并且是好的，有时候有许多小任务会降低调度的性能。

我看到有人在某些情况下使用GNU Parallel和slurm，它是否提供任何优势？

GNU Parallel具有非常强大的工具来生成作业步骤，例如计算一对参数的所有成对可能值，或者对文件进行高级全局匹配等。

它还允许用单个Bash命令替换几行代码来处理所有步骤的启动。

这是一个可能的用例吗？

是的，你可以使用它，但它不会帮助你做出关于你的主要问题的决策。

- damienfrancois