问SLURM‘`srun`’vs‘`sbatch`’及其参数

EN

文件上说

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不能做的。

它们之间有什么关系，对于srun和sbatch，它们有什么不同？

所有参数--ntasks、--nodes、--cpus-per-task、--ntasks-per-node在这两个命令中都有相同的含义。除了--exclusive之外，几乎所有参数都是如此。

究竟是什么“罩下”导致了这种情况呢？

srun立即在远程主机上执行脚本，而sbatch则在内部存储中复制脚本，然后在作业开始时将其上载到计算节点。您可以在提交脚本提交后修改提交脚本来检查它；更改将不会被考虑到(请参阅这)。

它们是如何相互作用的，它们各自的“规范”用例是什么？

您通常使用sbatch在提交脚本中提交作业，并在Slurm调用它们时使用srun创建作业步骤。srun用于启动进程。如果您的程序是一个并行的MPI程序，srun负责创建所有的MPI进程。如果没有，srun将按照--ntasks选项指定的次数运行您的程序。有许多用例取决于您的程序是否并行，运行时间是否长，是否由单个可执行文件组成，等等。除非另有规定，srun默认继承它运行的sbatch或salloc的相关选项(来自这里)。

具体来说，我会单独使用srun吗？

除了小测试之外，没有。一个常见的用途是srun --pty bash来获取计算作业上的shell。

这并不能完全回答这个问题，但我发现一些更多的信息可能会对未来的人有所帮助：

来自一个具有类似问题的我找到的相关线索：

简而言之，sbatch和salloc为作业分配资源，而srun则跨这些资源启动并行任务。当在作业分配中调用时，srun将跨部分或所有分配的资源启动并行任务。在这种情况下，srun默认继承运行它的sbatch或salloc的相关选项。然后(通常)可以提供srun不同的选项，这些选项将覆盖默认接收的内容。作业中对srun的每次调用都称为作业步骤。 还可以在作业分配之外调用srun。在这种情况下，srun请求资源，当这些资源被授予时，作为单个作业和作业步骤在这些资源中启动任务。 有一个相对较新的网页，深入到更详细的-B和-排他性选项。 doc/html/cpu_management.shtml ement.shtml

来自SLURM常见问题页面的其他信息。

srun命令有两种不同的操作模式。首先，如果没有在现有作业中运行(即没有在salloc或S批处理创建的Slurm作业分配中)，那么它将创建一个作业分配并生成一个应用程序。如果在现有分配中运行，srun命令只生成应用程序。对于这个问题，我们将只讨论第一种操作模式，并比较使用sbatch和srun命令创建作业分配。 srun命令是为交互式使用而设计的，有人监视输出。应用程序的输出被看作是srun命令的输出，通常在用户终端上。sbatch命令设计为提交脚本以供以后执行，并将其输出写入文件。作业分配中使用的命令选项几乎相同。选项中最明显的区别是sbatch命令支持作业数组的概念，而srun则不支持。另一个显著的差异是容错。涉及批处理作业的失败通常会导致重新请求并再次执行作业，而涉及srun的失败通常会导致生成错误消息，期望用户以适当的方式进行响应。

另一次相关谈话这里