SLURM `srun` vs `sbatch` and their parameters

Question

我正在尝试理解SLURM的srun和sbatch命令之间的区别。我希望得到一般性的解释，而不是针对以下问题的具体答案，但以下这些困惑的具体点可以作为起点并给出我所寻找的想法。

根据文档，srun用于提交作业，sbatch用于提交稍后执行的作业，但实际区别不清楚，它们的行为似乎相同。例如，我有一个由两个节点组成的集群，每个节点有两个CPU。如果我连续5次执行srun testjob.sh &，它会将第五个作业排队等待CPU可用，就像执行sbatch testjob.sh一样。

为了让问题更具体，我认为一个好的开始是：使用其中一个命令可以做些什么，而使用另一个命令则不能，并且为什么？ 这两个命令的许多参数都是相同的。看起来最相关的是--ntasks、--nodes、--cpus-per-task和--ntasks-per-node。 它们如何相互关联，以及在srun与sbatch之间有何不同？ 一个特定的区别是，如果testjob.sh没有可执行权限，即chmod +x testjob.sh，那么srun会导致错误，而sbatch则会愉快地运行它。 发生了什么“幕后”，导致这种情况发生？ 文档还提到，srun通常在sbatch脚本中使用。这引出了问题：它们如何相互作用，每个命令的“规范”用例是什么？具体而言，我是否会单独使用srun？

- dkv

Answer 1

文档说明

srun is used to submit a job for execution in real time

当

sbatch is used to submit a job script for later execution.

他们都接受几乎相同的参数集。主要区别在于，srun是交互式和阻塞的（您会在终端中得到结果，并且在完成之前无法编写其他命令），而sbatch是批处理和非阻塞的（结果写入文件，您可以立即提交其他命令）。

如果您使用带有&符号的srun后台运行，则可以删除srun的“阻止”功能，它变为交互式但非阻塞。但它仍然是交互式的，这意味着输出将混杂在您的终端中，并且srun进程与您的终端相关联。如果您断开连接，则会失去对它们的控制，或者它们可能会被杀死（基本上取决于它们是否使用stdout）。如果您连接到提交作业的机器重新启动，则它们将被终止。

如果您使用sbatch，则提交您的作业并由Slurm处理；您可以断开连接，关闭终端等而不会产生任何影响。您的工作不再链接到正在运行的进程中。

“我可以用一个做些什么，而用另一个却做不到，为什么？”

一个只能用于sbatch而不能用于srun的特性是作业数组。由于srun可以在sbatch脚本中使用，因此没有什么你不能通过sbatch实现。所有参数--ntasks、--nodes、--cpus-per-task、--ntasks-per-node 在两个命令中意义相同。这对于几乎所有参数都是正确的，但有一个明显的例外，即--exclusive。发生了什么事情导致这种情况呢？ 立即在远程主机上执行脚本，而 则将脚本复制到内部存储器中，然后在作业启动时将其上传到计算节点。您可以通过在提交后修改提交脚本来检查此操作；更改不会被考虑（参见 this）。

它们如何相互交互，以及每个的“典型”用例是什么？

您通常使用sbatch来提交作业，在提交脚本中使用srun创建作业步骤，正如Slurm所称。 srun用于启动进程。如果您的程序是并行MPI程序，则srun负责创建所有MPI进程。如果不是，则srun将根据--ntasks选项指定的次数运行您的程序。根据您的程序是否并行化，是否具有长时间运行时间，是否由单个可执行文件组成等，有许多用例。除非另有说明，默认情况下，srun继承sbatch或salloc的相关选项（从here）。

具体而言，我何时会仅使用srun？

除了进行小型测试之外，没有。常见用法是srun --pty bash在计算作业上获取shell。

- damienfrancois

---

谢谢您的问题，这比我想象中要好得多。有一个后续问题，因为这是我最初困惑的地方之一：在提交脚本中为什么要调用srun？也许我对“作业步骤”的意义感到困惑。例如，如果我有一个名为runjob.sh的脚本，其中包含#!/bin/bash srun myjob.sh，那么调用（a）sbatch runjob.sh与（b）sbatch myjob.sh与（c）srun myjob.sh与（d）srun runjob.sh之间是否存在实际区别？（显然，最后一个很愚蠢，但我很好奇）。 - dkv

也许你可以浏览我最近进行的一次培训课程的幻灯片，了解如何在提交脚本中使用srun的想法：http://www.cism.ucl.ac.be/Services/Formations/slurm/2016/slurm.pdf - damienfrancois

幻灯片中的所有示例（以及CECI页面上的教程）似乎都在sbatch提交脚本中使用srun。 然而，我发现在提交脚本中没有srun的命令也会以同样的方式运行。 我提到的四个调用之间是否实际上有区别？ - dkv

只有在两个条件同时满足时，你提供的所有示例才会以相同的方式运行：(1) 分配给一个CPU，(2) 程序是纯顺序的。要看到差异，请请求多个任务。另一个区别是，如果在sbatch中不使用srun，sstat命令将不会返回任何有用的信息。 - damienfrancois

@damienfrancois 谢谢，你的演示看起来很棒！今天可以通过Web Archive访问：http://web.archive.org/web/20220505010613/https://www.cism.ucl.ac.be/Services/Formations/slurm/2016/slurm.pdf - undefined

Answer 2

这并没有完全回答问题，但是我在这里找到了一些更多的信息，或许对未来有所帮助：

从一个相关的线程中（链接）得到类似问题的解释：

简而言之，sbatch和salloc分配作业所需的资源，而srun在这些资源上启动并行任务。当在一个作业分配内被调用时，srun会在分配的某些或全部资源上启动并行任务。在这种情况下，srun默认继承其运行下的sbatch或salloc的相关选项。然后，您可以为srun提供通常会覆盖默认值的不同选项。每个作业内srun的调用称为作业步骤。

srun也可以在作业分配外被调用。此时，srun请求资源，并在授权这些资源后将任务作为单个作业步骤，在这些资源上启动任务。

还有一个相对较新的网页详细介绍了-B和--exclusive选项。

doc/html/cpu_management.shtml

另附SLURM FAQ 页的其他信息：

srun命令有两种不同的操作模式。首先，如果未在现有作业中运行（即未在salloc或sbatch创建的Slurm作业分配中），则会创建一个作业分配并生成一个应用程序。如果在现有分配内运行，则srun命令仅生成应用程序。对于这个问题，我们只讨论第一种操作模式，并比较使用sbatch和srun命令创建作业分配。

srun命令专为交互使用而设计，需要有人监控输出。应用程序的输出被视为srun命令的输出，通常在用户的终端上看到。sbatch命令旨在提交脚本以供后续执行，并将其输出写入文件。在作业分配中使用的命令选项几乎相同。选项中最明显的差异是，sbatch命令支持作业数组的概念，而srun不支持。另一个重要的区别在于容错性。与sbatch作业相关的故障通常导致重新排队并再次执行作业，而与srun相关的故障通常会生成错误消息，预计用户将选择适当的响应方式。

另外在这里有一段相关对话。

- dkv