CPU 管理用户和管理员指南
概述
本指南的目的是帮助 Slurm 用户和管理员选择配置选项，并编写命令行以管理作业、步骤和任务对 CPU 资源的使用。该文档分为以下几个部分：
通过用户命令进行的 CPU 管理受到 Slurm 管理员选择的配置参数的限制。不同 CPU 管理选项之间的相互作用复杂，且往往难以预测。可能需要一些实验来发现所需的选项组合以产生期望的结果。用户和管理员应参考 slurm.conf、cgroup.conf、salloc、sbatch 和 srun 的手册页以获取每个选项的详细说明。以下 HTML 文档也可能有用：
Slurm 中的可消耗资源
共享可消耗资源
对多核/多线程架构的支持
平面分布
Slurm 执行的 CPU 管理步骤
Slurm 使用四个基本步骤来管理作业/步骤的 CPU 资源：
步骤 1：选择节点
在步骤 1 中，Slurm 从中选择要分配给作业或作业步骤的 CPU 资源的节点集合。因此，节点选择受到许多控制 CPU 分配的配置和命令行选项的影响（见步骤 2）。如果配置了 SelectType=select/linear，则将把选定节点上的所有资源分配给作业/步骤。如果 SelectType 配置为 select/cons_tres，则可以从选定节点分配单独的插槽、核心和线程作为 可消耗资源。可消耗资源类型由 SelectTypeParameters 定义。
步骤 1 由 slurmctld 和 select 插件执行。
|
slurm.conf 参数 |
可能值 |
描述 |
|
<节点名称> |
定义 一个节点。这包括节点上的板、插槽、核心、线程和处理器（逻辑 CPU）的数量和布局。 |
|
|
<分区名称> |
定义 一个分区。分区定义的几个参数影响节点的选择（例如，节点、超额订阅、最大节点数） |
|
|
config_overrides |
控制 节点定义中信息的使用方式。 |
|
|
select/linear | select/cons_tres |
控制 CPU 资源是以整个节点的单位分配给作业和作业步骤，还是作为可消耗资源（插槽、核心或线程）进行分配。 |
|
|
CR_CPU | CR_CPU_Memory | CR_Core |
CR_Core_Memory | CR_Socket | CR_Socket_Memory |
定义 可消耗资源类型，并控制 select 插件的 CPU 资源分配的其他方面。 |
|
命令行选项 |
可能值 |
描述 |
|
<插槽[:核心[:线程]]> |
限制 节点选择为具有指定插槽、核心和线程布局的节点。 |
|
|
<列表> |
限制 节点选择为具有指定属性的节点 |
|
|
不适用 |
限制 节点选择为连续的节点 |
|
|
<核心> |
限制 节点选择为每个插槽至少具有指定数量的核心的节点 |
|
|
<ncpus> |
控制 分配给每个任务的 CPU 数量 |
|
|
不适用 |
防止 与其他作业共享分配的节点。将 CPU 子分配给作业步骤。 |
|
|
<节点文件> |
包含要为作业选择的特定节点列表的文件（仅适用于 salloc 和 sbatch） |
|
|
compute_bound | memory_bound | [no]multithread |
对 CPU 资源分配的额外控制 |
|
|
<n> |
控制 每个节点分配的最小 CPU 数量 |
|
|
<最小节点[-最大节点]> |
控制 分配给作业的最小/最大节点数 |
|
|
<数量> |
控制 为作业创建的任务数量 |
|
|
<数量> |
控制 每个分配核心的最大任务数量 |
|
|
<数量> |
控制 每个分配插槽的最大任务数量 |
|
|
<数量> |
控制 每个分配节点的最大任务数量 |
|
|
不适用 |
允许 分配的 CPU 数量少于任务数量 |
|
|
<分区名称> |
控制 作业使用的分区 |
|
|
不适用 |
允许 与其他作业共享分配的节点 |
|
|
<插槽> |
限制 节点选择为至少具有指定数量的插槽的节点 |
|
|
<线程> |
限制 节点选择为每个核心至少具有指定数量的线程的节点 |
|
|
<host1,host2,... 或文件名> |
要分配给作业的特定节点列表 |
|
|
<host1,host2,... 或文件名> |
要排除在作业分配之外的特定节点列表 |
|
|
不适用 |
绕过 正常分配（仅限于“SlurmUser”和“root”用户的特权选项） |
步骤 2：从选定节点分配 CPU
在步骤2中，Slurm从步骤1中选择的节点集合中为作业/步骤分配CPU资源。因此，CPU分配受到与节点选择相关的配置和命令行选项的影响。
如果SelectType=select/linear被配置，所有选定节点上的资源将被分配给作业/步骤。如果SelectType被配置为select/cons_tres，则可以从选定节点分配单个插槽、核心和线程作为可消耗资源。可消耗资源类型由SelectTypeParameters.
当使用SelectType为select/cons_tres时，节点之间的默认分配方法是块分配（在使用另一个节点之前分配节点中所有可用的CPU）。节点内的默认分配方法是循环分配（在节点内的插槽之间以轮询方式分配可用的CPU）。用户可以使用下面描述的适当命令行选项覆盖默认行为。分配方法的选择可能会影响分配给作业/步骤的特定CPU。
步骤2由slurmctld和选择插件执行。
|
slurm.conf参数 |
可能的值 |
描述 |
|
<节点名称> |
定义一个节点。这包括节点上的板、插槽、核心、线程和处理器（逻辑CPU）的数量和布局。 |
|
|
<分区名称> |
定义一个分区。分区定义的几个参数会影响CPU资源分配给作业（例如，节点、超分配、最大节点数） |
|
|
config_overrides |
控制节点定义中信息的使用方式。 |
|
|
select/linear | select/cons_tres |
控制CPU资源是以整个节点的单位分配给作业和作业步骤，还是作为可消耗资源（插槽、核心或线程）分配。 |
|
|
CR_CPU | CR_CPU_Memory | CR_Core |
CR_Core_Memory | CR_Socket | CR_Socket_Memory |
定义可消耗资源类型，并控制选择插件的CPU资源分配的其他方面。 |
|
命令行选项 |
可能的值 |
描述 |
|
block|cyclic |
第一个指定的分配（在“:”之前）控制任务分配给每个选定节点的顺序。请注意，此选项不影响分配给每个节点的任务数量，仅影响分配的顺序。 |
|
|
<number> |
控制每个核心分配的任务数量 |
步骤3：将任务分配到选定的节点
在步骤3中，Slurm将任务分配给步骤1中为作业/步骤选择的节点。每个任务仅分配给一个节点，但可以将多个任务分配给每个节点。除非为作业指定了CPU的超分配，否则分配给节点的任务数量受限于节点上分配的CPU数量和每个任务的CPU数量。如果配置了可消耗资源，或者允许资源共享，则来自多个作业/步骤的任务可以在同一节点上并发运行。
步骤3由slurmctld执行。
|
slurm.conf参数 |
可能的值 |
描述 |
|
<number> |
控制作业步骤可以在单个节点上生成的最大任务数量 |
|
命令行选项 |
可能的值 |
描述 |
|
block|cyclic |
第一个指定的分配（在“:”之前）控制任务分配给每个选定节点的顺序。请注意，此选项不影响分配给每个节点的任务数量，仅影响分配的顺序。 |
|
|
<number> |
控制每个核心分配的任务数量 |
<数字>
控制每个分配核心的最大任务数
<数字>
控制每个分配插槽的最大任务数
<数字>
控制每个分配节点的最大任务数
不适用
控制 作业步骤使用哪个节点
第 4 步：在节点内将任务可选地分配和绑定到 CPU
在可选的第 4 步中，Slurm 将每个任务分配并绑定到在第 3 步中分配的节点上指定的 CPU 子集。分配到同一节点的不同任务可以绑定到相同的 CPU 子集或不同的子集。此步骤称为任务亲和性或任务/CPU 绑定。
第 4 步由 slurmd 和任务插件执行。
|
slurm.conf 参数 |
可能的值 |
描述 |
|
task/none | task/affinity | task/cgroup |
控制此步骤是否启用以及使用哪个任务插件 |
|
cgroup.conf 参数 |
可能的值 |
描述 |
|
yes|no |
控制作业是否被限制在其分配的 CPU 上 |
|
命令行选项 |
可能的值 |
描述 |
|
见手册页 |
控制任务与 CPU 的绑定 （仅限 srun） |
|
|
<数字> |
控制每个分配核心的最大任务数 |
|
|
block|cyclic |
第二个指定的分配（在“：”之后）控制任务在节点内分配到 CPU 的顺序，以便将任务绑定到 CPU |
关于 CPU 管理步骤的附加说明
对于可消耗资源，用户需要理解 CPU 分配（第 2 步）和任务亲和性/绑定（第 4 步）之间的区别。独占（不共享）分配 CPU 作为可消耗资源限制了可以同时使用节点的作业/步骤/任务的数量。但它并不限制分配到该节点的每个任务可以使用的 CPU 集。除非使用某种形式的 CPU/任务绑定（例如，任务或 spank 插件），否则所有分配到节点的任务都可以使用节点上的所有 CPU，包括未分配给其作业/步骤的 CPU。这可能会对性能产生意想不到的不利影响，因为它允许一个作业使用专门分配给另一个作业的 CPU。因此，可能不建议在未配置任务亲和性的情况下配置可消耗资源。请注意，当配置选择/线性（整个节点分配）时，任务亲和性也可能有助于通过限制每个任务到特定插槽或节点上的其他 CPU 资源子集来提高性能。
获取作业/步骤/任务的 CPU 使用信息
没有简单的方法可以为作业/步骤（分配、分配和绑定）生成全面的 CPU 管理信息。然而，几个命令/选项提供了有关 CPU 使用的有限信息。
|
命令/选项 |
信息 |
|
scontrol show job 选项： --details |
此选项提供了为作业选择的节点列表以及每个节点上分配给作业的 CPU id。请注意，此命令报告的 CPU id 是 Slurm 抽象 CPU id，而不是 Linux/硬件 CPU id（例如，通过 /proc/cpuinfo 报告）。 |
|
Linux 命令：env |
手册。Slurm 环境变量提供与节点和 CPU 使用相关的信息：
|
|
srun 选项： --cpu-bind=verbose |
此选项提供了任务亲和性用于将任务绑定到 CPU 的 CPU 掩码列表。 请注意，这些掩码所表示的 CPU id 是 Linux/硬件 CPU id，而不是 Slurm 抽象 CPU id，如 scontrol 等报告。 |
|
srun/salloc/sbatch 选项： -l |
此选项将任务 id 作为前缀添加到发送到 stdout/stderr 的每行输出中。 这对于区分多任务作业/步骤的任务 id 的节点相关和 CPU 相关信息非常有用。 |
|
Linux 命令： |
给定任务的 pid（如果命令由任务本身执行，则为“self”），此命令生成绑定到任务的 CPU id 列表。这与 --cpu-bind=verbose 提供的信息相同，但以更可读的格式显示。 |
关于 CPU 编号的说明
Slurm 所知的逻辑 CPU 的数量和布局在 slurm.conf 的节点定义中描述。这可能与实际硬件上的物理 CPU 布局不同。因此，Slurm 生成其自己的内部或“抽象”CPU 编号。这些编号可能与 Linux 所知的物理或“机器”CPU 编号不匹配。
CPU 管理与 Slurm 计费
Slurm 用户的 CPU 管理受 Slurm 计费施加的限制。计费限制可以在用户、组和集群级别上应用于 CPU 使用。有关详细信息，请参见 sacctmgr 手册页。
CPU 管理示例
以下示例说明了使用 Slurm 管理 CPU 资源的一些场景。还有许多其他场景是可能的。在每个示例中，假设每个节点上的所有 CPU 都可用于分配。
- 示例节点和分区配置
- 示例 1：分配整个节点
- 示例 2：将核心简单分配为可消耗资源
- 示例 3：在节点之间平衡分配的可消耗资源
- 示例 4：最小化资源碎片的可消耗资源
- 示例 5：将任务循环分配到节点的可消耗资源
- 示例 6：默认分配和将任务平面分配到节点的可消耗资源
- 示例 7：将 CPU 过度分配给任务的可消耗资源
- 示例 8：在作业之间共享资源的可消耗资源
- 示例 9：在多线程节点上分配每个核心仅一个线程的可消耗资源
- 示例 10：具有任务亲和性和核心绑定的可消耗资源
- 示例 11：具有任务亲和性和插槽绑定的可消耗资源，案例 1
- 示例 12：具有任务亲和性和插槽绑定的可消耗资源，案例 2
- 示例 13：具有任务亲和性和插槽绑定的可消耗资源，案例 3
- 示例 14：具有任务亲和性和自定义分配和分配的可消耗资源
- 示例 15：具有任务亲和性以优化多任务、多线程作业性能的可消耗资源
- 示例 16：具有任务 cgroup 的可消耗资源
示例节点和分区配置
对于这些示例，Slurm 集群包含以下节点：
|
节点名称 |
n0 |
n1 |
n2 |
n3 |
|
插槽数量 |
2 |
2 |
2 |
2 |
|
每个插槽的核心数量 |
4 |
4 |
4 |
4 |
|
核心总数 |
8 |
8 |
8 |
8 |
|
每个核心的线程（CPU）数量 |
1 |
1 |
1 |
2 |
|
CPU 总数 |
8 |
8 |
8 |
16 |
以及以下分区：
|
分区名称 |
regnodes |
hypernode |
|
节点 |
n0 n1 n2 |
n3 |
|
默认 |
是 |
- |
这些实体在 slurm.conf 中定义如下：
Nodename=n0 NodeAddr=node0 Sockets=2 CoresPerSocket=4 ThreadsPerCore=1 Procs=8 Nodename=n1 NodeAddr=node1 Sockets=2 CoresPerSocket=4 ThreadsPerCore=1 Procs=8 State=IDLE Nodename=n2 NodeAddr=node2 Sockets=2 CoresPerSocket=4 ThreadsPerCore=1 Procs=8 State=IDLE Nodename=n3 NodeAddr=node3 Sockets=2 CoresPerSocket=4 ThreadsPerCore=2 Procs=16 State=IDLE PartitionName=regnodes Nodes=n0,n1,n2 OverSubscribe=YES Default=YES State=UP PartitionName=hypernode Nodes=n3 State=UP
这些示例展示了使用 cons_tres 插件。
示例 1：分配整个节点
为作业分配至少两个整个节点。
slurm.conf 选项：
SelectType=select/linear
命令行：
srun --nodes=2 ...
备注：
SelectType=select/linear 配置选项指定以整个节点为单位进行分配。 --nodes=2 srun 选项使 Slurm 至少为作业分配 2 个节点。示例 2：将核心简单分配为可消耗资源
一个作业需要 6 个 CPU（2 个任务和每个任务 3 个 CPU，没有过度分配）。从默认分区中的单个节点分配这 6 个 CPU 作为可消耗资源。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core
命令行：
srun --nodes=1-1 --ntasks=2 --cpus-per-task=3 ...
备注：
该 SelectType 配置选项将核心定义为可消耗资源。 --nodes=1-1 srun 选项 限制作业在单个节点上。以下表格显示了该作业可能的分配模式。
|
节点名称 |
n0 |
n1 |
n2 |
|
已分配的CPU数量 |
6 |
0 |
0 |
|
任务数量 |
2 |
0 |
0 |
示例 3：在节点之间均衡分配的可消耗资源
一个作业需要 9 个 CPU（3 个任务，每个任务 3 个 CPU，没有超额承诺）。 从默认分区中的 3 个节点中分配 3 个 CPU。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core
命令行：
srun --nodes=3-3 --ntasks=3 --cpus-per-task=3 ...
备注：
这些选项指定了作业的以下条件：3 个任务，每个任务 3 个独特的 CPU，使用恰好 3 个节点。为了满足这些条件，Slurm 必须从每个节点分配 3 个 CPU。以下表格显示了该作业的分配情况。
|
节点名称 |
n0 |
n1 |
n2 |
|
已分配的CPU数量 |
3 |
3 |
3 |
|
任务数量 |
1 |
1 |
1 |
示例 4：可消耗资源的最小化资源碎片化
一个作业需要 12 个 CPU（12 个任务，每个任务 1 个 CPU，没有超额承诺）。使用最少数量的节点和最少数量的插槽分配 CPU，以最小化集群中已分配/未分配 CPU 的碎片化。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core,CR_CORE_DEFAULT_DIST_BLOCK
命令行：
srun --ntasks=12 ...
备注：
节点之间的默认分配方法是块。这最小化了作业所使用的节点数量。配置选项 CR_CORE_DEFAULT_DIST_BLOCK 将节点内的默认分配方法设置为块。这最小化了作业在节点内使用的插槽数量。这两种方法的组合导致 Slurm 使用最少数量的节点（2 个节点）和插槽（3 个插槽）分配 12 个 CPU。以下表格显示了该作业的可能分配模式。
|
节点名称 |
n0 |
n1 |
n2 |
|||
|
插槽 ID |
0 |
1 |
0 |
1 |
0 |
1 |
|
已分配的CPU数量 |
4 |
4 |
4 |
0 |
0 |
0 |
|
任务数量 |
8 |
4 |
0 |
|||
示例 5：可消耗资源的任务在节点之间循环分配
一个作业需要 12 个 CPU（6 个任务，每个任务 2 个 CPU，没有超额承诺）。从默认分区中的 2 个节点中各分配 6 个 CPU。将任务循环分配到节点。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core
命令行：
srun --nodes=2-2 --ntasks-per-node=3 --distribution=cyclic
--ntasks=6 --cpus-per-task=2 ...
备注：
这些选项指定了作业的以下条件：6 个任务，每个任务 2 个独特的 CPU，使用恰好 2 个节点，每个节点 3 个任务。为了满足这些条件，Slurm 必须从这 2 个节点中各分配 6 个 CPU。--distribution=cyclic 选项导致任务以循环方式分配到节点。以下表格显示了该作业的可能分配和分布模式。
|
节点名称 |
n0 |
n1 |
n2 |
|
已分配的CPU数量 |
6 |
6 |
0 |
|
任务数量 |
3 |
3 |
0 |
|
任务分配到节点的分布，按任务 ID |
0 |
1 |
- |
示例 6：可消耗资源的默认分配和任务在节点之间的平面分布
一个作业需要 16 个 CPU（8 个任务，每个任务 2 个 CPU，没有超额承诺）。使用默认分区中的所有 3 个节点。将任务以每两个为一组的方式循环分配到每个节点。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core
命令行：
srun --nodes=3-3 --distribution=plane=2 --ntasks=8 --cpus-per-task=2 ...
备注：
这些选项指定了作业的以下条件：8 个任务，每个任务 2 个独特的 CPU，使用默认分区中的所有 3 个节点。为了满足这些条件，Slurm 使用节点之间的默认分配方法（块）分配 8 个 CPU，从第一个节点分配 8 个 CPU，从第二个节点分配 6 个 CPU，从第三个节点分配 2 个 CPU。--distribution=plane=2 选项导致 Slurm 以每两个为一组的方式将任务分配到每个节点，受每个节点上分配的 CPU 数量的限制。因此，例如，只有 1 个任务分配到第三个节点，因为该节点上仅分配了 2 个 CPU，而每个任务需要 2 个 CPU。以下表格显示了该作业的可能分配和分布模式。
|
节点名称 |
n0 |
n1 |
n2 |
|
已分配的CPU数量 |
8 |
6 |
2 |
|
任务数量 |
4 |
3 |
1 |
|
任务分配到节点的分布，按任务 ID |
0
1 |
2
3 |
4 |
示例 7：可消耗资源的 CPU 超额分配给任务
一个作业有 20 个任务。在单个节点上运行该作业。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core
命令行：
srun --nodes=1-1 --ntasks=20 --overcommit ...
备注：
选项 --overcommit 允许作业仅在一个节点上运行，通过超额分配 CPU 给任务。以下表格显示了该作业的可能分配和分布模式。
|
节点名称 |
n0 |
n1 |
n2 |
|
已分配的CPU数量 |
8 |
0 |
0 |
|
任务数量 |
20 |
0 |
0 |
|
任务分配到节点的分布，按任务 ID |
0 - 19 |
- |
- |
示例 8：可消耗资源在作业之间共享
两个作业每个需要 6 个 CPU（每个作业 6 个任务，没有超额承诺）。在单个节点上同时运行这两个作业。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core
命令行：
srun --nodes=1-1 --nodelist=n0 --ntasks=6 --oversubscribe ... srun --nodes=1-1 --nodelist=n0 --ntasks=6 --oversubscribe ...
备注：
选项 --nodes=1-1 和 --nodelist=n0 srun 选项一起将两个作业限制在节点 n0 上。分区定义中的 OverSubscribe=YES 选项加上 --oversubscribe srun 选项允许两个作业在节点上超额分配 CPU。
示例 9：在多线程节点上的可消耗资源，每个核心仅分配一个线程
一个作业需要 8 个 CPU（8 个任务，没有超额承诺）。在节点 n3 上运行该作业，仅分配每个核心一个线程。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_CPU
命令行：
srun --partition=hypernode --ntasks=8 --hint=nomultithread ...
备注：
配置选项 CR_CPU 使得每个核心仅分配一个线程。--hint=nomultithread srun 选项导致 Slurm 仅从每个核心分配一个线程给该作业。以下表格显示了该作业的可能分配模式。
" size="1">01
2
3
4
5
6
7
8
9
10
11
12
13
14
15
分配的CPU数量
4
4
分配的CPU ID
0 2 4 6
8 10 12 14
示例 10：具有任务亲和性和核心绑定的可消耗资源
一个作业需要 6 个 CPU（6 个任务且没有超分配）。在默认分区的单个节点中运行该作业。对每个任务应用核心绑定。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core TaskPlugin=task/affinity
命令行：
srun --nodes=1-1 --ntasks=6 --cpu-bind=cores ...
备注：
使用节点内的默认分配方法（循环），Slurm 在 1 个节点的每个插槽上分配 3 个 CPU。使用节点内的默认分发方法（循环），Slurm 将每个任务分配并绑定到跨插槽的分配核心，采用轮询方式。下表显示了该作业的可能分配、分发和绑定模式。例如，任务 ID 2 绑定到 CPU ID 1。
|
节点名称 |
n0 |
||||||||
|
插槽 ID |
0 |
1 |
|||||||
|
分配的CPU数量 |
3 |
3 |
|||||||
|
分配的CPU ID |
0 1 2 |
4 5 6 |
|||||||
|
任务与CPU的绑定 |
CPU ID |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
任务 ID |
0 |
2 |
4 |
- |
1 |
3 |
5 |
- |
|
示例 11：具有任务亲和性和插槽绑定的可消耗资源，案例 1
一个作业需要 6 个 CPU（6 个任务且没有超分配）。在默认分区的单个节点中运行该作业。对每个任务应用插槽绑定。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core TaskPlugin=task/affinity
命令行：
srun --nodes=1-1 --ntasks=6 --cpu-bind=sockets ...
备注：
使用节点内的默认分配方法（循环），Slurm 在 1 个节点的每个插槽上分配 3 个 CPU。使用节点内的默认分发方法（循环），Slurm 将每个任务分配并绑定到一个插槽中的所有分配 CPU，采用轮询方式。下表显示了该作业的可能分配、分发和绑定模式。例如，任务 ID 1、3 和 5 都绑定到 CPU ID 4、5 和 6。
|
节点名称 |
n0 |
||||||||
|
插槽 ID |
0 |
1 |
|||||||
|
分配的CPU数量 |
3 |
3 |
|||||||
|
分配的CPU ID |
0 1 2 |
4 5 6 |
|||||||
|
任务与CPU的绑定 |
CPU ID |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
任务 ID |
0 |
2 |
4 |
- |
1 |
3 |
5 |
- |
|
示例 12：具有任务亲和性和插槽绑定的可消耗资源，案例 2
一个作业需要 6 个 CPU（2 个任务，每个任务 3 个 CPU，且没有超分配）。在默认分区的单个节点中运行该作业。使用块分配方法分配核心。使用块分发方法分配核心。对每个任务应用插槽绑定。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core,CR_CORE_DEFAULT_DIST_BLOCK TaskPlugin=task/affinity
命令行：
srun --nodes=1-1 --ntasks=2 --cpus-per-task=3 --cpu-bind=sockets
--distribution=block:block ...
备注：
使用块分配方法，Slurm 在一个插槽上分配 4 个 CPU，在另一个插槽上分配 2 个 CPU。使用节点内的块分发方法，Slurm 将 3 个 CPU 分配给每个任务。应用插槽绑定后，Slurm 将每个任务绑定到所有分配的 CPU，这些 CPU 在任务分配的所有插槽中。下表显示了该作业的可能分配、分发和绑定模式。在此示例中，使用块分配方法，CPU ID 0-3 在插槽 ID 0 上分配，CPU ID 4-5 在插槽 ID 1 上分配。使用块分发方法，CPU ID 0-2 分配给任务 ID 0，CPU ID 3-5 分配给任务 ID 1。应用插槽绑定后，任务 ID 0 因此绑定到插槽 0 上的分配 CPU，而任务 ID 1 绑定到两个插槽上的分配 CPU。
|
节点名称 |
n0 |
||||||||
|
插槽 ID |
0 |
1 |
|||||||
|
分配的CPU数量 |
4 |
2 |
|||||||
|
分配的CPU ID |
0 1 2 3 |
4 5 |
|||||||
|
任务与CPU的绑定 |
CPU ID |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
任务 ID |
0 1 |
1 |
- |
||||||
示例 13：具有任务亲和性和插槽绑定的可消耗资源，案例 3
一个作业需要 6 个 CPU（2 个任务，每个任务 3 个 CPU，且没有超分配）。在默认分区的单个节点中运行该作业。使用块分配方法分配核心。使用循环分发方法分配核心。对每个任务应用插槽绑定。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core,CR_CORE_DEFAULT_DIST_BLOCK TaskPlugin=task/affinity
命令行：
srun --nodes=1-1 --ntasks=2 --cpus-per-task=3 --cpu-bind=sockets
--distribution=block:cyclic ...
备注：
使用块分配方法，Slurm 在一个插槽上分配 4 个 CPU，在另一个插槽上分配 2 个 CPU。使用节点内的循环分发方法，Slurm 将 3 个 CPU 分配给每个任务。应用插槽绑定后，Slurm 将每个任务绑定到所有分配的 CPU，这些 CPU 在任务分配的所有插槽中。下表显示了该作业的可能分配、分发和绑定模式。在此示例中，使用块分配方法，CPU ID 0-3 在插槽 ID 0 上分配，CPU ID 4-5 在插槽 ID 1 上分配。使用循环分发方法，CPU ID 0、1 和 4 分配给任务 ID 0，CPU ID 2、3 和 5 分配给任务 ID 1。应用插槽绑定后，因此两个任务都绑定到两个插槽上的分配 CPU。
|
节点名称 |
n0 |
||||||||
|
插槽 ID |
0 |
1 |
|||||||
|
分配的CPU数量 |
4 |
2 |
|||||||
|
分配的CPU ID |
0 1 2 3 |
4 5 |
|||||||
|
任务与CPU的绑定 |
CPU ID |
0 |
1 |
2 |
0 1 2 3 |
4 5 |
|||
|
任务与CPU的绑定 |
CPU id |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
任务 ids |
0 1 |
0 1 |
- |
||||||
示例 14：具有任务亲和性和自定义分配与分配的可消耗资源
一个作业需要 18 个 CPU（18 个任务且没有超额承诺）。在默认分区中运行该作业。使用块分配在每个节点上分配 6 个 CPU。使用循环分配任务到节点和块分配任务进行 CPU 绑定。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core,CR_CORE_DEFAULT_DIST_BLOCK TaskPlugin=task/affinity
命令行：
srun --nodes=3-3 --ntasks=18 --ntasks-per-node=6
--distribution=cyclic:block --cpu-bind=cores ...
评论：
此示例展示了使用任务亲和性与自定义 CPU 分配和任务在节点间及节点内的分配进行绑定。srun 选项指定了作业的以下条件：18 个任务，每个任务 1 个唯一 CPU，使用分区中的所有 3 个节点，每个节点 6 个任务。CR_CORE_DEFAULT_DIST_BLOCK 配置选项指定在节点内的块分配。为了满足这些条件，Slurm 在每个节点上分配 6 个 CPU，其中一个插槽上分配 4 个 CPU，另一个插槽上分配 2 个 CPU。--distribution=cyclic:block 选项指定将任务循环分配到节点，并在节点内进行块分配以进行 CPU 绑定。下表展示了该作业的可能分配、分配和绑定模式。例如，任务 id 10 绑定到节点 n1 的 CPU id 3。
|
节点名称 |
n0 |
n1 |
n2 |
||||||||||||||||||||||
|
插槽 id |
0 |
1 |
0 |
1 |
0 |
1 |
|||||||||||||||||||
|
分配的 CPU 数量 |
3 |
0 |
3 |
0 |
3 |
0 |
|||||||||||||||||||
|
分配的 CPU ids |
0 1 2 |
0 1 2 |
0 1 2 |
||||||||||||||||||||||
|
任务数量 |
1 |
1 |
1 |
||||||||||||||||||||||
|
任务分配到节点，按任务 id |
0 |
1 |
2 |
||||||||||||||||||||||
|
任务与 CPU 的绑定 |
CPU id |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
||||||||
|
任务 id |
0 |
3 |
6 |
9 |
12 |
15 |
- |
- |
1 |
4 |
7 |
10 |
13 |
16 |
- |
- |
2 |
5 |
8 |
11 |
14 |
17 |
- |
- |
|
示例 15：具有任务亲和性的可消耗资源以优化多任务、多线程作业的性能
一个作业需要 9 个 CPU（3 个任务，每个任务 3 个 CPU且没有超额承诺）。在默认分区中运行该作业，管理 CPU 以优化作业的性能。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core,CR_CORE_DEFAULT_DIST_BLOCK TaskPlugin=task/affinity
命令行：
srun --ntasks=3 --cpus-per-task=3 --ntasks-per-node=1 --cpu-bind=cores ...
评论：
为了优化该作业的性能，用户希望从每个插槽分配 3 个 CPU，并将每个任务绑定到单个插槽中的 3 个 CPU。SelectTypeParameters 配置选项指定了可消耗资源类型为核心，并在节点内进行块分配。TaskPlugin 配置选项启用任务亲和性。srun 选项指定了作业的以下条件：3 个任务，每个任务 3 个唯一 CPU，每个节点 1 个任务。为了满足这些条件，Slurm 在默认分区中的 3 个节点的每个插槽中分配 3 个 CPU。--cpu-bind=cores 选项使 Slurm 将每个任务绑定到分配的 3 个 CPU 上。下表展示了该作业的可能分配、分配和绑定模式。例如，任务 id 2 绑定到节点 n2 的插槽 id 0 上的 CPU ids 0、1 和 2。
|
节点名称 |
n0 |
n1 |
n2 |
||||||||||||||||||||||
|
插槽 id |
0 |
1 |
0 |
1 |
0 |
1 |
|||||||||||||||||||
|
分配的 CPU 数量 |
3 |
0 |
3 |
0 |
3 |
0 |
|||||||||||||||||||
|
分配的 CPU ids |
0 1 2 |
0 1 2 |
0 1 2 |
||||||||||||||||||||||
|
任务数量 |
1 |
1 |
1 |
||||||||||||||||||||||
|
任务分配到节点，按任务 id |
0 |
1 |
2 |
||||||||||||||||||||||
|
任务与 CPU 的绑定 |
CPU id |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
||||||||
|
任务 id |
0 |
3 |
6 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|||||||
|
任务 ID |
0 |
- |
1 |
- |
2 |
-- |
|||||||||||||||||||
示例 16：带有任务 cgroup 的可消耗资源
一个作业需要 6 个 CPU（6 个任务，没有超额承诺）。在默认分区的单个节点上运行该作业。
slurm.conf 选项：
SelectType=select/cons_tres SelectTypeParameters=CR_Core TaskPlugin=task/cgroup
cgroup.conf 选项：
ConstrainCores=yes
命令行：
srun --nodes=1-1 --ntasks=6 ...
备注：
task/cgroup 插件当前仅支持在节点内分配核心的块方法。Slurm 将任务分配给核心，但没有 CPU 绑定，每个任务可以访问所有分配的 CPU。以下表格显示了该作业的可能分配、分布和绑定模式。
|
节点名称 |
n0 |
||||||||
|
插槽 ID |
0 |
1 |
|||||||
|
分配的 CPU 数量 |
4 |
2 |
|||||||
|
分配的 CPU ID |
0 1 2 3 |
4 5 |
|||||||
|
任务与 CPU 的绑定 |
CPU ID |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
任务 ID |
0-5 |
0-5 |
- |
||||||
task/cgroup 插件不将任务绑定到 CPU。要将任务绑定到 CPU，并访问所有任务分配选项，可以将 task/affinity 插件与 task/cgroup 插件一起使用：
TaskPlugin=task/cgroup,task/affinity
最后修改日期 2024 年 1 月 4 日