Parallel processing SLURM`srun`vs`sbatch`及其参数

我试图理解SLURM和commands之间的区别。对于以下问题，我很乐意给出一个一般性的解释，而不是具体的答案，但这里有一些具体的困惑点，可以作为一个起点，让我了解我在寻找什么

根据，

srun

用于提交作业，

sbatch

用于提交作业以供以后执行，但我不清楚实际区别，它们的行为似乎是相同的。例如，我有一个有2个节点的集群，每个节点有2个CPU。如果我连续执行

srun testjob.sh&

5x，它将很好地排队等待第五个作业，直到CPU可用，执行

sbatch testjob.sh

为了使问题更具体，我认为一个好的起点可能是：我可以用其中一个做哪些事情而不能用另一个做，为什么？

两个命令的许多参数是相同的。最相关的是

--ntasks

，

--节点

，

--每个任务的CPU

，

--每个节点的ntasks

它们之间是如何相互关联的，它们在

srun

与

sbatch

之间有何区别？

一个特别的区别是，如果

testjob.sh

没有可执行权限，即

chmod+x testjob.sh

而

sbatch

将愉快地运行它，则

srun

将导致错误引擎盖下发生了什么导致这种情况的发生？

文档中还提到，

srun

通常在

sbatch

脚本中使用。这就引出了一个问题：它们如何相互作用，以及它们各自的“规范”用例是什么？具体来说，我是否会单独使用

srun

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

当

它们都接受几乎相同的参数集。主要区别在于，

srun

是交互式的和阻塞的（您在终端中获得结果，在完成之前无法编写其他命令），而

sbatch

是批处理和非阻塞的（结果写入文件，您可以立即提交其他命令）

如果在后台使用

srun

和

符号，则删除
srun
的“阻塞”功能，该功能变为交互式但非阻塞。但它仍然是交互式的，这意味着输出将使您的终端混乱，并且
srun
进程链接到您的终端。如果断开连接，您将失去对它们的控制，否则它们可能会被杀死（取决于它们是否基本上使用
stdout
）。如果您连接以提交作业的计算机重新启动，它们将被杀死

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

有哪些事情我可以用一个做，而用另一个做不了，为什么

可用于
sbatch
而不可用于
srun
的功能是。由于
srun
可以在
sbatch
脚本中使用，因此没有什么是您不能使用
sbatch
的

这些是如何相互关联的，srun和sbatch的区别是什么

所有参数
--ntasks
，
--nodes
，
--cpu per task
，
--ntasks per node
在两个命令中的含义相同。这几乎适用于所有参数，但
--exclusive
除外

是什么“幕后操纵”导致了这种情况

srun
立即在远程主机上执行脚本，而
sbatch
将脚本复制到内部存储器中，然后在作业启动时将其上载到计算节点上。您可以在提交后通过修改提交脚本进行检查；将不考虑更改（请参阅）

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

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

具体来说，我会自己使用srun吗

除了小型测试之外，没有。一个常见的用法是在计算作业中使用
srun--pty bash
获取shell。
这实际上并不能完全回答这个问题，但下面是我发现的一些对将来的人可能有帮助的更多信息：


来自一个有类似问题的人：

简而言之，sbatch和salloc将资源分配给作业，而srun则跨这些资源启动并行任务。在作业分配中调用时，srun将跨部分或所有分配的资源启动并行任务。在这种情况下，默认情况下，srun会继承其运行的sbatch或salloc的相关选项。然后，您可以（通常）提供srun不同的选项，这些选项将覆盖默认接收的内容。在作业中每次调用srun都称为作业步骤

srun也可以在ou中调用
sbatch is used to submit a job script for later execution.