salloc
部分：Slurm 命令 (1)更新：Slurm 命令
索引
名称
salloc - 获取 Slurm 作业分配（节点集），执行命令， 并在命令完成后释放分配。概要
salloc [选项(0)...] [ : [选项(N)...]] [命令(0) [参数(0)...]]
选项定义了在共同调度的异构作业中的多个作业。
有关异构作业的更多详细信息，请参见文档
https://slurm.schedmd.com/heterogeneous_jobs.html
描述
salloc 用于分配 Slurm 作业分配，这是一组资源 （节点），可能带有一些约束（例如每个 节点的处理器数量）。当 salloc 成功获得请求的分配时，它将运行 用户指定的命令。最后，当用户指定的命令完成后，salloc 释放作业分配。命令可以是用户希望的任何程序。一些典型的命令是 xterm、包含 srun 命令的 shell 脚本和 srun（见示例 部分）。如果未指定命令，则 salloc 将运行用户的默认 shell。
以下文档描述了各种选项对
作业和任务的 CPU 分配的影响。
https://slurm.schedmd.com/cpu_management.html
注意：salloc 逻辑包括支持保存和恢复终端 行设置，并设计为在前台执行。如果您需要 在后台执行 salloc，请将其标准输入设置为某个文件，例如："salloc -n16 a.out </dev/null &"
返回值
如果 salloc 无法执行用户命令，它将 返回 1 并将错误打印到 stderr。否则，如果成功或被信号 HUP、INT、KILL 或 QUIT 杀死：它将返回 0。命令路径解析
如果提供了命令，则按以下顺序解析：
1. 如果命令以 "." 开头，则路径构造为：
当前工作目录 / 命令
2. 如果命令以 "/" 开头，则路径被视为绝对路径。
3. 如果命令可以通过 PATH 解析。见 path_resolution(7)。
4. 如果命令在当前工作目录中。
当前工作目录是调用进程的工作目录，除非 --chdir 参数被传递，这将覆盖当前工作 目录。
选项
- -A, --account=<账户>
- 将此作业使用的资源计费到指定账户。 账户 是一个任意字符串。作业提交后，可以使用 scontrol 命令更改账户名称。
-
- --acctg-freq=<数据类型>=<间隔>[,<数据类型>=<间隔>...]
- 定义作业计费和分析采样间隔（以秒为单位）。 这可以用于覆盖 slurm.conf 文件中的 JobAcctGatherFrequency 参数。<数据类型>=<间隔> 指定作业acct_gather 插件的任务 采样间隔或分析类型的采样间隔 由 acct_gather_profile 插件提供。可以指定多个 以逗号分隔的 <数据类型>=<间隔> 对。支持的 数据类型 值包括：
任务采样间隔的默认值为 30 秒。
所有其他间隔的默认值为 0。
间隔为 0 将禁用指定类型的采样。
如果任务采样间隔为 0，则仅在作业终止时收集
计费信息（减少 Slurm 对作业的干扰）。
较小的（非零）值对作业性能的影响更大，
但对于少于 10,000 个任务的应用程序，30 秒的值不太可能被注意到。
https://slurm.schedmd.com/burst_buffer.html
https://slurm.schedmd.com/burst_buffer.html
时间可以是 HH:MM:SS 的形式，以在 特定的时间运行作业（秒是可选的）。 （如果该时间已经过去，则假定为第二天。） 您还可以指定 午夜、中午、十一点（上午 11 点）、 下午茶（下午 3 点）或 茶点时间（下午 4 点），并且您可以在早上或晚上运行时 使用 AM 或 PM 后缀。 您还可以通过指定 MMDDYY 或 MM/DD/YY YYYY-MM-DD 的日期来说明作业将在何时运行。将日期和时间结合使用，格式为 YYYY-MM-DD[THH:MM[:SS]]。您还可以 给出类似 现在 + 计数 时间单位 的时间，其中时间单位 可以是 秒（默认）、分钟、小时、 天 或 周，并且您可以告诉 Slurm 在今天运行 作业，使用关键字 今天，并在明天运行 作业，使用关键字 明天。 在作业提交后，可以使用 scontrol 命令更改值。 例如：
--begin=16:00 --begin=now+1hour --begin=now+60 (默认以秒为单位) --begin=2010-01-20T12:34:00
-
关于日期/时间规格的说明：
- 尽管 'seconds' 字段 的 HH:MM:SS 时间 规格 是 代码允许的，但请注意，Slurm 调度程序的轮询时间 不够精确，无法保证在确切的 秒上调度作业。作业将在指定时间之后的下一个轮询 开始。确切的轮询间隔取决于 Slurm 调度程序（例如，默认调度/内置为 60 秒）。
- 如果未指定时间（HH:MM:SS），默认值为（00:00:00）。
- 如果指定了没有年份的日期（例如，MM/DD）， 则假定为当前年份，除非 MM/DD 和 HH:MM:SS 的组合 在该年份已经过去，在这种情况下将使用下一年。
注意：可更改特性是由 NodeFeatures 插件定义的特性。
支持的 --constraint 选项包括：
-
- 单一名称
- 仅使用具有指定特性的节点。 例如，--constraint="intel"
-
- 节点计数
- 请求可以通过在特性名称后附加星号和计数来指定所需的节点数。
例如，--nodes=16 --constraint="graphics*4"
表示作业需要 16 个节点，并且至少四个节点必须具有特性 "graphics."
如果请求多个特性并使用节点计数，请求
必须用方括号括起来。
注意：此选项不受 NodeFeatures 插件的支持。 可以使用异构作业代替。
-
- AND
- 仅使用具有所有指定特性的节点。 使用和符号作为 AND 运算符。 例如，--constraint="intel&gpu"
-
- OR
- 仅使用具有至少一个指定特性的节点。 使用竖线作为 OR 运算符。如果未请求可更改特性，则 分配中的节点可以具有不同的特性。例如， salloc -N2 --constraint="intel|amd" 可以导致作业分配 其中一个节点具有 intel 特性，另一个节点具有 amd 特性。 但是，如果表达式包含可更改特性，则所有 OR 运算符 将自动视为匹配 OR，以便作业 分配中的所有节点具有相同的特性集。例如， salloc -N2 --constraint="foo|bar&baz" 作业分配两个节点，其中两个节点都具有 foo，或 bar 和 baz（一个 或两个节点可以具有 foo、bar 和 baz）。NodeFeatures 插件 将找到匹配作业 分配中所有节点的第一组节点特性；这些特性被设置为节点上的活动特性，并传递给 RebootProgram（见 slurm.conf(5)）和辅助脚本（见 helpers.conf(5)）。在这种情况下，辅助插件使用 匹配两个节点的 "foo" 或 "bar,baz" 的第一个。
-
- 匹配 OR
- 如果一组可能的选项中的只有一个应该用于所有分配的 节点，则使用 OR 运算符并将选项放在方括号内。 例如，--constraint="[rack1|rack2|rack3|rack4]" 可能 用于指定所有节点必须在集群的单个机架上分配，但可以使用这四个机架中的任何一个。
-
- 多个计数
- 可以使用 AND 运算符并将选项放在方括号内来指定多个资源的特定计数。
例如，--constraint="[rack1*2&rack2*4]" 可能
用于指定必须从具有 "rack1" 特性的节点中分配两个节点，并且必须从具有 "rack2" 特性的节点中分配四个节点。
注意：此构造不支持多个 Intel KNL NUMA 或 MCDRAM 模式。例如，--constraint="[(knl&quad)*2&(knl&hemi)*4]" 不受支持，而 --constraint="[haswell*2&(knl&hemi)*4]" 是支持的。 指定多个 KNL 模式需要使用异构作业。
注意：此选项不受 NodeFeatures 插件的支持。
注意：多个计数可能导致作业分配具有非最佳 网络布局。
-
- 方括号
- 方括号可用于指示您正在寻找具有
不同要求的节点集，这些要求包含在方括号内。例如，
--constraint="[(rack1|rack2)*1&(rack3)*2]" 将为您获取一个具有
"rack1" 或 "rack2" 特性的节点和两个具有 "rack3" 特性的节点。
如果请求多个特性并使用节点计数，请求
必须用方括号括起来。
注意：方括号仅保留用于 多个计数 和 匹配 OR 语法。 AND 运算符要求每个特性在方括号内都有一个计数 （即 "[quad*2&hemi*1]"）。Slurm 仅允许每个作业有一组括起来的 约束。
注意：方括号不受 NodeFeatures 插件的支持。可以使用竖线字符请求匹配 OR，而不需要方括号，前提是至少有一个可更改的特性。
-
- 括号
- 括号可用于将相似的节点特性分组。例如， --constraint="[(knl&snc4&flat)*4&haswell*1]" 可能用于指定 需要四个具有 "knl"、"snc4" 和 "flat" 特性的节点和一个具有 "haswell" 特性的节点。 括号也可以用于分组操作。如果没有括号，节点 特性将严格从左到右解析。 例如， --constraint="foo&bar|baz" 请求具有 foo 和 bar 或 baz 的节点。 --constraint="foo|bar&baz" 请求具有 foo 和 baz 或 bar 和 baz 的节点（请注意，baz 与所有内容进行了 AND 操作）。 --constraint="foo&(bar|baz)" 请求具有 foo 和至少 一个 bar 或 baz 的节点。 注意：括号内的 OR 不应与 KNL NodeFeatures 插件一起使用，但受辅助 NodeFeatures 插件的支持。
注意：此选项仅适用于 topology/flat 插件。 其他拓扑插件会修改节点顺序并阻止此选项生效。
注意：显式设置作业的专用核心值隐式设置 --exclusive 选项。
注意：如果未指定 -n，此选项可能隐式设置任务数（每个请求的线程一个任务）。
请求在此分配内由 srun 命令启动的作业步骤 尽可能以某个请求的频率运行，针对计算节点上为步骤选择的 CPU。
p1 可以是 [#### | low | medium | high | highm1]，这将设置 频率 scaling_speed 为相应的值，并将频率 scaling_governor 设置为 UserSpace。有关值的定义，请参见下文。
p1 可以是 [Conservative | OnDemand | Performance | PowerSave]，这将 将 scaling_governor 设置为相应的值。该治理者必须在 slurm.conf 选项 CpuFreqGovernors 中设置。
当 p2 存在时，p1 将是最小缩放频率，p2 将是最大缩放频率。在这种情况下，治理者 p3 或 CpuFreqDef 不能是 UserSpace，因为它不支持范围。
p2 可以是 [#### | medium | high | highm1]。p2 必须大于 p1，并且与 UserSpace 治理者不兼容。
p3 可以是 [Conservative | OnDemand | Performance | PowerSave | SchedUtil | UserSpace]，这将把治理者设置为相应的值。
如果 p3 是 UserSpace，则频率 scaling_speed、scaling_max_freq 和 scaling_min_freq 将静态设置为 p1 定义的值。
任何请求的频率低于可用的最小频率将被四舍五入到可用的最小频率。同样，任何请求的频率 高于可用的最大频率将被四舍五入到可用的最大频率。
slurm.conf 中的 CpuFreqDef 参数将用于在没有 p3 的情况下设置治理者。如果没有 CpuFreqDef，默认治理者将使用每个 CPU 中设置的系统当前治理者。因此，不允许在没有 CpuFreqDef 或特定治理者的情况下指定范围。
目前可接受的值包括：
在请求 --cpu-freq 选项时，将在作业 步骤中设置以下信息环境变量。
SLURM_CPU_FREQ_REQ
如果在发出 'srun' 命令时设置了此环境变量，则该环境变量也可以用于提供 CPU 频率请求的值。 命令行上的 --cpu-freq 将覆盖 环境变量值。环境变量的形式与命令行相同。 有关 SLURM_CPU_FREQ_REQ 变量的描述，请参见 环境变量 部分。
注意：此参数被视为请求，而不是要求。 如果作业步骤的节点不支持设置 CPU 频率，或者 请求的值超出合法频率的范围，则记录错误，但允许作业步骤继续。
注意：仅为作业步骤的 CPU 设置频率 意味着任务被限制在这些 CPU 上。如果未配置任务 限制（即启用任务/亲和性 TaskPlugin，或启用任务/cgroup TaskPlugin，并在 cgroup.conf 中设置了 "ConstrainCores=yes"），则忽略此参数。
注意：当步骤完成时，每个 选定 CPU 的频率和治理者将重置为先前的值。
注意：使用 --cpu-freq 选项提交作业 时，使用 linuxproc 作为 ProctrackType 可能导致作业在 计费能够轮询作业信息之前运行得太快。因此，并非所有 计费信息都会存在。
例如， 考虑一个具有 4 个任务的应用程序，每个任务需要 3 个处理器。如果我们的 集群由四核节点组成，我们只要求 12 个处理器，控制器可能只给我们 3 个节点。然而，通过使用 --cpus-per-task=3 选项，控制器知道每个任务需要 3 个处理器在同一节点上，控制器将授予 4 个节点的分配，每个任务一个。
有效的时间格式为：
HH:MM[:SS] [AM|PM]
MMDD[YY] 或 MM/DD[/YY] 或 MM.DD[.YY]
MM/DD[/YY]-HH:MM[:SS]
YYYY-MM-DD[THH:MM[:SS]]]
now[+count[seconds(default)|minutes|hours|days|weeks]]
-d afterok:20:21,afterany:23意味着作业只能在作业 20 和 21 返回代码为 0 并且作业 23 完成后运行。然而：
-d afterok:20:21?afterany:23意味着任何条件（afterok:20 或 afterok:21 或 afterany:23） 都足以释放作业。 许多作业可以共享相同的依赖关系，这些作业甚至可以属于 不同的用户。作业提交后，可以使用 scontrol 命令更改值。 在联邦中允许对远程作业的依赖关系。 一旦作业依赖关系由于前一个作业的终止状态而失败， 依赖作业将永远不会运行，即使前一个作业重新排队并且在后续执行中具有不同的终止状态。
-
- after:job_id[[+时间][:jobid[+时间]...]]
- 在指定的作业启动或取消后以及从作业 启动或取消发生的 '时间'（以分钟为单位）后，此 作业可以开始执行。如果未给出 '时间'，则在 启动或取消后没有延迟。
-
- afterany:job_id[:jobid...]
- 此作业可以在指定的作业终止后开始执行。 这是默认的依赖类型。
-
- afterburstbuffer:job_id[:jobid...]
- 此作业可以在指定的作业终止后以及 任何相关的突发缓冲区阶段输出操作完成后开始执行。
-
- aftercorr:job_id[:jobid...]
- 此作业数组的任务可以在指定作业中对应的任务 ID 成功完成后开始执行（以零的退出代码完成）。
-
- afternotok:job_id[:jobid...]
- 此作业可以在指定的作业以某种失败状态终止后开始执行（非零退出代码、节点故障、超时等）。 此作业必须在指定作业仍处于活动状态时提交，或在指定作业结束后的 MinJobAge 秒内提交。
-
- afterok:job_id[:jobid...]
- 此作业可以在指定的作业成功执行后开始执行（以零的退出代码完成）。 此作业必须在指定作业仍处于活动状态时提交，或在指定作业结束后的 MinJobAge 秒内提交。
-
- singleton
- 此作业可以在任何先前启动的作业 共享相同作业名称和用户的作业终止后开始执行。 换句话说，在任何时候，只能运行或挂起一个由该名称和该用户拥有的作业。 在联邦中，单例依赖关系必须在所有集群上满足， 除非在 slurm.conf 中使用 DependencyParameters=disable_remote_singleton。
指定远程进程的替代分配方法。 对于作业分配，这设置将用于 后续 srun 请求的环境变量，并且还会影响将为 作业分配选择哪些核心。
此选项控制将任务分配到已分配资源的节点，以及将这些资源 分配给任务以进行绑定（任务亲和性）。第一个分配 方法（在第一个 ":" 之前）控制将任务分配到节点。 第二个分配方法（在第一个 ":" 之后） 控制将分配的 CPU 在插槽之间分配以绑定 到任务。第三个分配方法（在第二个 ":" 之后）控制 将分配的 CPU 在核心之间分配以绑定到任务。 仅在启用任务亲和性时，第二和第三个分配适用。 第三个分配仅在配置了任务/cgroup 插件时支持。每种分配类型的默认值由 * 指定。
请注意，对于 select/cons_tres，分配给每个插槽和节点的 CPU 数量可能不同。有关资源分配、任务分配到 节点和任务绑定到 CPU 的更多信息，请参见 mc_support 文档。
-
第一个分配方法（任务在节点之间的分配）：
- *
-
- 使用将任务分配到节点的默认方法（块）。
-
- 块
-
- 块分配方法将任务分配到节点，使得连续的任务共享一个节点。例如，考虑一个 分配有三个节点，每个节点有两个 CPU。四任务块 分配请求将把这些任务分配到节点上，任务一和二在第一个节点上，任务三在第二个节点上， 任务四在第三个节点上。如果任务数超过分配的节点数， 块分配是默认行为。
-
- 循环
-
- 循环分配方法将任务分配到节点，使得连续的任务在连续的节点上分配（采用轮询方式）。例如，考虑分配三个节点，每个节点有两个 CPU。四个任务的循环分配请求将把这些任务分配到节点上，其中任务一和四在第一个节点，任务二在第二个节点，任务三在第三个节点。 注意，当 SelectType 为 select/cons_tres 时，可能不会在每个节点上分配相同数量的 CPU。任务分配将在所有尚未分配给任务的 CPU 的节点之间轮询。 如果任务数量不大于分配的节点数量，则循环分配是默认行为。
-
- 平面
-
- 任务以大小 <size> 的块分配。必须指定大小或设置 SLURM_DIST_PLANESIZE。分配给每个节点的任务数量与循环分配相同，但分配给每个节点的任务 ID 取决于平面大小。此选项不能与其他分配规范组合。 有关更多详细信息（包括示例和图表），请参见 mc_support 文档和 https://slurm.schedmd.com/dist_plane.html
-
- 任意
-
- 任意分配方法将按照环境变量 SLURM_HOSTFILE 指定的文件中的顺序分配进程。如果列出了此变量，它将覆盖任何指定的其他方法。如果未设置，则默认方法为块。 主机文件中必须至少包含请求的主机数量，并且每行一个或用逗号分隔。如果指定任务数量（-n，--ntasks=<number>），您的任务将在节点上按照文件的顺序排列。
注意：作业分配上的任意分配选项仅控制分配给作业的节点，而不控制这些节点上 CPU 的分配。此选项主要用于控制 srun 命令中现有作业分配的作业步骤任务布局。
注意：如果给出了任务数量并且也给出了请求的节点列表，则如果列表中的节点数量大于任务数量，则将使用的节点数量将减少以匹配任务数量。 - 任意分配方法将按照环境变量 SLURM_HOSTFILE 指定的文件中的顺序分配进程。如果列出了此变量，它将覆盖任何指定的其他方法。如果未设置，则默认方法为块。 主机文件中必须至少包含请求的主机数量，并且每行一个或用逗号分隔。如果指定任务数量（-n，--ntasks=<number>），您的任务将在节点上按照文件的顺序排列。
-
第二种分配方法（在插槽间分配 CPU 以进行绑定）：
- *
-
- 使用默认方法在插槽间分配 CPU（循环）。
-
- 块
-
- 块分配方法将连续从同一插槽分配已分配的 CPU 以绑定到任务，然后使用下一个连续的插槽。
-
- 循环
-
- 循环分配方法将为给定任务连续从同一插槽分配已分配的 CPU，并从下一个连续的插槽为下一个任务分配，以在插槽之间以轮询方式进行分配。 需要多个 CPU 的任务将尽可能在单个插槽上分配所有这些 CPU。
注意：在启用超线程的节点上，未请求完整核心的任务可能会在插槽之间分配。可以通过指定 --ntasks-per-core=1 来避免这种情况，这将强制任务分配完整的核心。 - 循环分配方法将为给定任务连续从同一插槽分配已分配的 CPU，并从下一个连续的插槽为下一个任务分配，以在插槽之间以轮询方式进行分配。 需要多个 CPU 的任务将尽可能在单个插槽上分配所有这些 CPU。
-
- fcyclic
-
- fcyclic 分配方法将从连续的插槽中以轮询方式分配已分配的 CPU 以绑定到任务。 需要多个 CPU 的任务将在插槽之间以循环方式分配每个 CPU。
-
第三种分配方法（在核心间分配 CPU 以进行绑定）：
- *
-
- 使用默认方法在核心间分配 CPU（继承自第二种分配方法）。
-
- 块
-
- 块分配方法将连续从同一核心分配已分配的 CPU 以绑定到任务，然后使用下一个连续的核心。
-
- 循环
-
- 循环分配方法将为给定任务连续从同一核心分配已分配的 CPU，并从下一个连续的核心为下一个任务分配，以在核心之间以轮询方式进行分配。
-
- fcyclic
-
- fcyclic 分配方法将从连续的核心中以轮询方式分配已分配的 CPU 以绑定到任务。
-
对节点上的任务分配的可选控制：
- 打包
-
- 与其在分配的节点上均匀分配作业步骤的任务，不如尽可能紧密地将它们打包在节点上。 这仅适用于使用“块”任务分配方法时。
-
- 不打包
-
- 与其将作业步骤的任务尽可能紧密地打包在节点上，不如均匀分配它们。 此用户选项将优先于 SelectTypeParameters CR_Pack_Nodes 配置参数。
注意：此选项与 --oversubscribe 互斥。
如果启用 SchedulerParameters=extra_constraints，则此字符串用于根据每个节点的 Extra 字段进行节点过滤。
注意：这些选项不指定资源分配大小。 每个指定的值被视为最小值。 星号 (*) 可以用作占位符，表示要利用所有可用的该类型资源。值也可以指定为最小-最大。各个级别也可以在单独的选项中指定：
--sockets-per-node=<sockets>
--cores-per-socket=<cores>
--threads-per-core=<threads>
如果启用任务/亲和插件，则以这种方式指定的分配也会导致后续启动的任务绑定到线程，如果 -B 选项指定了线程计数，否则绑定到核心计数，如果指定了核心计数，则绑定到插槽计数。
如果 SelectType 配置为 select/cons_tres，则必须具有 CR_Core、CR_Core_Memory、CR_Socket 或 CR_Socket_Memory 参数，以使此选项生效。
如果未指定，scontrol show job 将显示 'ReqS:C:T=*:*:*'。此选项适用于作业分配。
注意：此选项与 --hint、--threads-per-core 和 --ntasks-per-core 互斥。
注意：如果未指定 -n，此选项可能隐式设置任务数量（每个请求的线程一个任务）。
支持的value 定义：
注意：分配必须包含每个节点至少一个 GPU，或者如果使用类型，则每个节点每种 GPU 类型一个。如果不同节点需要不同的 GPU 类型，请使用异构作业。
-
- 每个共享多个任务
-
- 否定 每个共享一个任务。如果在 SelectTypeParameters 中默认设置，则此选项非常有用。
-
- 禁用绑定
-
- 否定 强制绑定。如果在 SelectTypeParameters 中默认设置，则此选项非常有用。
-
- 强制绑定
-
- 作业可用的唯一 CPU 将是绑定到所选 GRES 的 CPU（即在 gres.conf 文件中标识的 CPU 将严格执行）。此选项可能导致作业启动延迟。 例如，要求两个 GPU 和一个 CPU 的作业将被延迟，直到单个插槽上的两个 GPU 可用，而不是使用绑定到不同插槽的 GPU，但是，由于通信速度的提高，应用程序性能可能会得到改善。 要求节点配置有多个插槽，并且资源过滤将在每个插槽的基础上执行。
注意：此选项可以在 SelectTypeParameters 中默认设置。
注意：此选项特定于 SelectType=cons_tres。
注意：如果尝试在多个插槽上的多个 GRES 上强制绑定，此选项可能会产生未定义的结果。 - 作业可用的唯一 CPU 将是绑定到所选 GRES 的 CPU（即在 gres.conf 文件中标识的 CPU 将严格执行）。此选项可能导致作业启动延迟。 例如，要求两个 GPU 和一个 CPU 的作业将被延迟，直到单个插槽上的两个 GPU 可用，而不是使用绑定到不同插槽的 GPU，但是，由于通信速度的提高，应用程序性能可能会得到改善。 要求节点配置有多个插槽，并且资源过滤将在每个插槽的基础上执行。
-
- 每个共享一个任务
-
- 不允许不同任务从同一共享 GRES 中分配共享 GRES。
注意：仅在使用 --tres-per-task 请求共享 GRES 时强制执行此标志。
注意：此选项可以在 SelectTypeParameters=ONE_TASK_PER_SHARING_GRES 中默认设置。
注意：此选项特定于 SelectTypeParameters=MULTIPLE_SHARING_GRES_PJ - 不允许不同任务从同一共享 GRES 中分配共享 GRES。
注意：此选项隐含某些相关选项的特定值，这阻止其与任何用户指定的 --ntasks-per-core、--threads-per-core 或 -B 值一起使用。 这些冲突选项在作为命令行参数指定时将覆盖 --hint。如果冲突选项作为环境变量指定，则命令行参数中的 --hint 将优先。
注意：在提交异构作业时，许可证请求只能在第一个组件作业上进行。 例如“salloc -L ansys:2 :”。
注意：如果在 AccountingStorageTres 中跟踪许可证，并且使用了 OR，则 ReqTRES 将显示所有请求的 tres 以逗号分隔。AllocTRES 将仅显示分配给作业的许可证。
注意：当作业请求 OR 的许可证时，Slurm 将尝试按照请求的顺序分配许可证。即使请求的其余许可证可以在请求的保留上满足，此指定顺序也将优先。这也适用于当 SchedulerParameters=bf_licenses 配置时的回填计划。
注意：内存大小为零的指定被视为特殊情况，并授予作业对每个节点上所有内存的访问权限。
注意：每个 slurmstepd 进程使用的内存包含在作业的总内存使用中。它通常消耗 20MiB 到 200MiB 之间的内存，尽管这可能会根据系统配置和任何加载的插件而有所不同。
注意：除非 Slurm 配置为使用强制机制，否则内存请求将不严格执行。有关更多详细信息，请参见 ConstrainRAMSpace 在 cgroup.conf(5) 手册页和 OverMemoryKill 在 slurm.conf(5) 手册页。
注意：要让 Slurm 始终报告在 shell 中执行的所有命令的所选内存绑定，可以通过将 SLURM_MEM_BIND 环境变量值设置为“verbose”来启用详细模式。
在使用 --mem-bind 时，将设置以下信息环境变量：
SLURM_MEM_BIND_LIST
SLURM_MEM_BIND_PREFER
SLURM_MEM_BIND_SORT
SLURM_MEM_BIND_TYPE
SLURM_MEM_BIND_VERBOSE
有关单个 SLURM_MEM_BIND* 变量的更详细描述，请参见 环境变量 部分。
支持的选项包括：
-
- 帮助
-
- 显示此帮助信息
-
- 本地
-
- 使用与正在使用的处理器本地的内存
-
- map_mem:<list>
-
- 通过在任务（或排名）上设置内存掩码进行绑定，如所指定的 <list> 为 <numa_id_for_task_0>,<numa_id_for_task_1>,...。 映射是为节点指定的，并且相同的映射应用于每个节点上的任务（即，每个节点上的最低任务 ID 映射到列表中指定的第一个 ID，依此类推）。 NUMA ID 被解释为十进制值，除非它们以 '0x' 开头，在这种情况下它们被解释为十六进制值。 如果任务（或排名）的数量超过此列表中的元素数量，则将根据需要从列表的开头重新使用列表中的元素。 为了简化对大量任务计数的支持，列表可以跟随带有星号和重复计数的映射。 例如“map_mem:0x0f*4,0xf0*4”。 为了获得可预测的绑定结果，作业中每个节点的所有 CPU 应分配给作业。
-
- mask_mem:<list>
-
- 通过在任务（或排名）上设置内存掩码进行绑定，如所指定的 <list> 为 <numa_mask_for_task_0>,<numa_mask_for_task_1>,...。 映射是为节点指定的，并且相同的映射应用于每个节点上的任务（即，每个节点上的最低任务 ID 映射到列表中指定的第一个掩码，依此类推）。 NUMA 掩码 始终 被解释为十六进制值。 请注意，如果掩码不以 [0-9] 开头，则必须在掩码前加上 '0x'，以便将其视为数值。 如果任务（或排名）的数量超过此列表中的元素数量，则将根据需要从列表的开头重新使用列表中的元素。 为了简化对大量任务计数的支持，列表可以跟随带有星号和重复计数的掩码。 例如“mask_mem:0*4,1*4”。 为了获得可预测的绑定结果，作业中每个节点的所有 CPU 应分配给作业。
-
- 无
-
- 不将任务绑定到内存（默认）
-
- 优先
-
- 优先使用第一个指定的 NUMA 节点，但允许
使用 其他 可用 NUMA 节点。 - 优先使用第一个指定的 NUMA 节点，但允许
-
- 安静
-
- 在任务运行之前安静地绑定（默认）
-
- 排名
-
- 按任务排名进行绑定（不推荐）
-
- 排序
-
- 对空闲缓存页面进行排序（在 Intel KNL 节点上运行 zonesort）
-
- 详细
-
- 在任务运行之前详细报告绑定
注意：如果作业请求的最终内存量无法由分区中配置的任何节点满足，则作业将被拒绝。 这可能发生在为作业分配使用了 --mem-per-cpu 和 --exclusive 选项，并且 --mem-per-cpu 乘以节点上的 CPU 数量大于该节点的总内存时。
注意：这适用于作业分配中的 可用 分配 CPU。 当配置了每个核心多个线程时，这一点很重要。 如果作业请求 --threads-per-core 的线程数少于核心上存在的线程数（或 --hint=nomultithread，这意味着 --threads-per-core=1），则作业将无法使用核心上的额外线程，并且这些线程将不包括在每个 CPU 的内存计算中。但是，如果作业可以访问核心上的所有线程，则即使作业未明确请求这些线程，这些线程也将包括在每个 CPU 的内存计算中。
在以下示例中，每个核心有两个线程。
在第一个示例中，由于未使用 --threads-per-core，因此两个任务可以在同一核心的不同超线程上运行。第三个任务使用第二个核心的两个线程。每个 CPU 分配的内存包括所有线程：
$ salloc -n3 --mem-per-cpu=100 salloc: Granted job allocation 17199 $ sacct -j $SLURM_JOB_ID -X -o jobid%7,reqtres%35,alloctres%35 JobID ReqTRES AllocTRES ------- ----------------------------------- ----------------------------------- 17199 billing=3,cpu=3,mem=300M,node=1 billing=4,cpu=4,mem=400M,node=1
在第二个示例中，由于 --threads-per-core=1，每个任务分配了整个核心，但只能使用每个核心的一个线程。分配的 CPU 包括每个核心上的所有线程。然而，每个 CPU 分配的内存仅包括每个核心中的可用线程。
$ salloc -n3 --mem-per-cpu=100 --threads-per-core=1 salloc: Granted job allocation 17200 $ sacct -j $SLURM_JOB_ID -X -o jobid%7,reqtres%35,alloctres%35 JobID ReqTRES AllocTRES ------- ----------------------------------- ----------------------------------- 17200 billing=3,cpu=3,mem=300M,node=1 billing=6,cpu=6,mem=300M,node=1
在所有情况下，作业分配请求 必须指定 --exclusive 选项。否则请求将被拒绝。
此外，使用这些选项的步骤不允许共享刀片，因此如果在刀片上运行的步骤未占用刀片上的所有节点，则资源将保持空闲。
network 选项在具有 HPE Slingshot 网络的系统上也可用。它可用于请求作业 VNI（用于作业中作业步骤之间的通信）。它还可用于覆盖为作业步骤分配的默认网络资源。可以在逗号分隔的列表中指定多个值。
-
- tcs=<class1>[:<class2>]...
- 要为应用程序配置的流量类别集。 支持的流量类别包括 DEDICATED_ACCESS、LOW_LATENCY、BULK_DATA 和 BEST_EFFORT。流量类别也可以指定为 TC_DEDICATED_ACCESS、TC_LOW_LATENCY、TC_BULK_DATA 和 TC_BEST_EFFORT。
-
- no_vni
- 不为此作业分配任何 VNI（即使是多节点）。
-
- job_vni
- 为此作业分配一个作业 VNI。
-
- single_node_vni
- 为此作业分配一个作业 VNI，即使它是单节点作业。
-
- adjust_limits
- 如果设置，slurmd 将通过获取每个 NIC 的最大资源数量并减去保留或使用的值（较高者）来设置网络资源保留的上限； 这是默认设置。
-
- no_adjust_limits
- 如果设置，slurmd 将仅根据每个资源的配置默认值和应用程序中的任务数量计算网络资源预留；它不会基于已经存在的系统网络服务的资源使用情况对这些预留请求设置上限。设置此项将意味着更多的应用程序启动可能会因网络资源耗尽而失败，但如果应用程序绝对需要一定数量的资源才能正常运行，此选项将确保这一点。
-
- disable_rdzv_get
- 禁用 Slingshot NIC 中的会合获取，这可以提高某些应用程序的性能。
-
- def_<rsrc>=<val>
- 为此资源分配每个 CPU 的保留分配。
-
- res_<rsrc>=<val>
- 为此资源分配每个节点的保留分配。如果设置，将覆盖每个 CPU 的分配。
-
- max_<rsrc>=<val>
- 此资源的每个节点的最大限制。
-
- depth=<depth>
- 每个 CPU 资源分配的乘数。默认值是节点上保留的 CPU 数量。
可以请求的资源包括：
指定可选参数 "off" 以禁用 SALLOC_NO_KILL 环境变量的效果。
默认情况下，如果其分配的任何节点失败，Slurm 将终止整个作业分配。
注意：此选项不能与任意分配一起使用。
注意：在使用 SelectType=select/linear 时不支持此选项。此值不能大于 --threads-per-core。
当应用于作业分配时（不包括请求独占访问节点的作业），资源的分配就像只请求每个节点一个任务一样。这意味着为每个任务请求的 CPU 数量（-c、--cpus-per-task）是按节点分配的，而不是乘以任务数。用于指定每个节点、插槽、核心等的任务数量的选项将被忽略。
当应用于作业步骤分配（在现有作业分配中执行 srun 命令）时，此选项可用于在每个 CPU 上启动多个任务。通常，srun 不会在每个 CPU 上分配超过一个进程。通过指定 --overcommit，您明确允许每个 CPU 超过一个进程。但是，每个节点允许执行的任务数不得超过 MAX_TASKS_PER_NODE。注意：MAX_TASKS_PER_NODE 在 slurm.h 文件中定义，并不是变量，它在 Slurm 构建时设置。
注意：此选项与 --exclusive 互斥。
有效的 type 值包括：
注意：请求的节点数必须始终能够被请求的段大小整除。
注意：段大小必须小于或等于规划的基础块大小。例如，对于基础块大小为 30 个节点的系统，"--segment 40" 将无效。
注意：此选项可能隐式设置任务数量（如果未指定 -n），每个请求的线程一个任务。
注意：显式设置作业的专用线程值隐式设置其 --exclusive 选项，为作业保留整个节点。
注意：此选项可能隐式设置任务数量（如果未指定 -n），每个请求的线程一个任务。
时间限制为零请求不施加时间限制。可接受的时间格式包括 "分钟"、"分钟:秒"、"小时:分钟:秒"、"天-小时"、"天-小时:分钟" 和 "天-小时:分钟:秒"。
示例： --tres-bind=gres/gpu:verbose,map:0,1,2,3+gres/nic:closest
默认情况下，大多数 tres 不会绑定到单个任务
支持的 type 选项绑定 gres：
-
- closest
- 将每个任务绑定到最近的 gres(s)。在 NUMA 环境中，每个任务可以绑定到多个 gres（即该 NUMA 环境中的所有 gres）。
-
- map:<list>
- 通过在任务（或排名）上设置 gres 掩码进行绑定，如所指定的，其中 <list> 是 <gres_id_for_task_0>,<gres_id_for_task_1>,... gres ID 被解释为十进制值。如果任务（或排名）的数量超过此列表中的元素数量，则列表中的元素将根据需要从列表的开头重新使用。为了简化对大任务计数的支持，列表可以跟随一个带有星号和重复计数的映射。例如 "map:0*4,1*4"。如果使用任务/cgroup 插件并在 cgroup.conf 中设置了 ConstrainDevices，则 gres ID 是相对于分配给作业的 gres 的零基索引（例如，第一个 gres 是 0，即使全局 ID 为 3）。否则，gres ID 是全局 ID，作业中的每个节点上的所有 gres 应该被分配以获得可预测的绑定结果。
-
- mask:<list>
- 通过在任务（或排名）上设置 gres 掩码进行绑定，如所指定的，其中 <list> 是 <gres_mask_for_task_0>,<gres_mask_for_task_1>,... 映射是为节点指定的，并且在每个节点上的任务应用相同的映射（即每个节点上的最低任务 ID 映射到列表中指定的第一个掩码，依此类推）。gres 掩码始终被解释为十六进制值，但可以加上可选的 '0x' 前缀。为了简化对大任务计数的支持，列表可以跟随一个带有星号和重复计数的映射。例如 "mask:0x0f*4,0xf0*4"。如果使用任务/cgroup 插件并在 cgroup.conf 中设置了 ConstrainDevices，则 gres ID 是相对于分配给作业的 gres 的零基索引（例如，第一个 gres 是 0，即使全局 ID 为 3）。否则，gres ID 是全局 ID，作业中的每个节点上的所有 gres 应该被分配以获得可预测的绑定结果。
-
- none
- 不将任务绑定到此 gres（关闭 --tres-per-task 和 --gpus-per-task 的隐式绑定）。
-
- per_task:<gres_per_task>
- 每个任务将绑定到指定数量的 gres，<gres_per_task>。任务优先分配与其分配中的核心相关的 gres，如 closest，尽管它们会在不可用时获取任何 gres。如果没有亲和性，第一个任务将分配节点上的前 x 个 gres 等等。共享的 gres 将优先绑定每个任务一个共享设备（如果可能）。
-
- single:<tasks_per_gres>
- 与 closest 相似，但每个任务只能绑定到单个 gres，即使它可以绑定到多个同样接近的 gres。要绑定的 gres 由 <tasks_per_gres> 确定，其中前 <tasks_per_gres> 个任务绑定到第一个可用的 gres，第二个 <tasks_per_gres> 个任务绑定到第二个可用的 gres，依此类推。这基本上是将任务块分配到可用的 gres 上，其中可用的 gres 由任务的插槽亲和性和 gres 的插槽亲和性（在 gres.conf 的 Cores 参数中指定）决定。
-
注意：共享 gres 绑定目前仅限于 per_task 或 none。
计数可以带有后缀
"k" 或 "K"（1024 的倍数），
"m" 或 "M"（1024 x 1024 的倍数），
"g" 或 "G"（1024 x 1024 x 1024 的倍数），
"t" 或 "T"（1024 x 1024 x 1024 x 1024 的倍数），
"p" 或 "P"（1024 x 1024 x 1024 x 1024 x 1024 的倍数）。
示例：
--tres-per-task=cpu=4 --tres-per-task=cpu=8,license/ansys=1 --tres-per-task=gres/gpu=1 --tres-per-task=gres/gpu:a100=2指定的资源将在每个节点上分配给作业。可跟踪资源的可用性由系统管理员配置。
注意：此选项与 gres/gpu 或 gres/shard 将隐式设置 --tres-bind=gres/[gpu|shard]:per_task:<tres_per_task>，或者如果指定了多个 gpu 类型 --tres-bind=gres/gpu:per_task:<gpus_per_task_type_sum>。可以通过显式的 --tres-bind 规范覆盖此设置。
注意：无效的 TRES 用于 --tres-per-task 包括 bb、billing、energy、fs、mem、node、pages、vmem。
-
- 0
- 在可以进行分配时立即开始执行。不要等待所有节点准备好使用（即启动）。
-
- 1
- 在所有节点准备好使用之前不要开始执行。
性能
执行 salloc 会向 slurmctld 发送远程过程调用。如果来自 salloc 或其他向 slurmctld 守护进程发送远程过程调用的 Slurm 客户端命令的调用足够多，可能会导致 slurmctld 守护进程的性能下降，可能导致拒绝服务。
请勿在 shell 脚本或其他程序的循环中运行 salloc 或其他向 slurmctld 发送远程过程调用的 Slurm 客户端命令。确保程序将对 salloc 的调用限制在收集所需信息的最低限度。
输入环境变量
在启动时，salloc 将读取并处理在以下环境变量中设置的选项。这些变量中的大多数以与上述定义的选项相同的方式设置。对于定义为不期望参数的标志选项，可以通过设置环境变量而不指定值（空或 NULL 字符串）、字符串 'yes' 或非零数字来启用该选项。环境变量的任何其他值将导致该选项未设置。以下是这些规则的几个例外。
注意：命令行选项始终覆盖环境变量设置。
- SALLOC_ACCOUNT
- 与 -A, --account 相同
-
- SALLOC_ACCTG_FREQ
- 与 --acctg-freq 相同
-
- SALLOC_BELL
- 与 --bell 相同
-
- SALLOC_BURST_BUFFER
- 与 --bb 相同
-
- SALLOC_CLUSTERS 或 SLURM_CLUSTERS
- 与 --clusters 相同
-
- SALLOC_CONSTRAINT
- 与 -C, --constraint 相同
-
- SALLOC_CONTAINER
- 与 --container 相同。
-
- SALLOC_CONTAINER_ID
- 与 --container-id 相同。
-
- SALLOC_CORE_SPEC
- 与 --core-spec 相同
-
- SALLOC_CPUS_PER_GPU
- 与 --cpus-per-gpu 相同
-
- SALLOC_DEBUG
- 与 -v, --verbose 相同，当设置为 1 时，设置为 2 时给出 -vv，等等。
-
- SALLOC_DELAY_BOOT
- 与 --delay-boot 相同
-
- SALLOC_EXCLUSIVE
- 与 --exclusive 相同
-
- SALLOC_GPU_BIND
- 与 --gpu-bind 相同
-
- SALLOC_GPU_FREQ
- 与 --gpu-freq 相同
-
- SALLOC_GPUS
- 与 -G, --gpus 相同
-
- SALLOC_GPUS_PER_NODE
- 与 --gpus-per-node 相同
-
- SALLOC_GPUS_PER_TASK
- 与 --gpus-per-task 相同
-
- SALLOC_GRES
- 与 --gres 相同
-
- SALLOC_GRES_FLAGS
- 与 --gres-flags 相同
-
- SALLOC_HINT 或 SLURM_HINT
- 与 --hint 相同
-
- SALLOC_IMMEDIATE
- 与 -I, --immediate 相同
-
- SALLOC_KILL_CMD
- 与 -K, --kill-command 相同
-
- SALLOC_MEM_BIND
- 与 --mem-bind 相同
-
- SALLOC_MEM_PER_CPU
- 与 --mem-per-cpu 相同
-
- SALLOC_MEM_PER_GPU
- 与 --mem-per-gpu 相同
-
- SALLOC_MEM_PER_NODE
- 与 --mem 相同
-
- SALLOC_NETWORK
- 与 --network 相同
-
- SALLOC_NO_BELL
- 与 --no-bell 相同
-
- SALLOC_NO_KILL
- 与 -k, --no-kill 相同
-
- SALLOC_OVERCOMMIT
- 与 -O, --overcommit 相同
-
- SALLOC_PARTITION
- 与 -p, --partition 相同
-
- SALLOC_POWER
- 与 --power 相同
-
- SALLOC_PROFILE
- 与 --profile 相同
-
- SALLOC_QOS
- 与 --qos 相同
-
- SALLOC_REQ_SWITCH
- 当使用树形拓扑时，这定义了作业分配所需的最大交换机数量，以及可选的等待该数量交换机的最大时间。请参见 --switches。
-
- SALLOC_RESERVATION
- 与 --reservation 相同
-
- SALLOC_SEGMENT_SIZE
- 与 --segment 相同
-
- SALLOC_SIGNAL
- 与 --signal 相同
-
- SALLOC_SPREAD_JOB
- 与 --spread-job 相同
-
- SALLOC_THREAD_SPEC
- 与 --thread-spec 相同
-
- SALLOC_THREADS_PER_CORE
- 与 --threads-per-core 相同
-
- SALLOC_TIMELIMIT
- 与 -t, --time 相同
-
- SALLOC_TRES_BIND
- 与 --tres-bind 相同
-
- SALLOC_TRES_PER_TASK
- 与 --tres-per-task 相同
-
- SALLOC_USE_MIN_NODES
- 与 --use-min-nodes 相同
-
- SALLOC_WAIT_ALL_NODES
- 与 --wait-all-nodes 相同。必须设置为 0 或 1 以禁用或启用该选项。
-
- SALLOC_WAIT4SWITCH
- 等待请求的交换机的最大时间。请参见 --switches
-
- SALLOC_WCKEY
- 与 --wckey 相同
-
- SLURM_CONF
- Slurm 配置文件的位置。
-
- SLURM_DEBUG_FLAGS
- 指定 salloc 使用的调试标志。请参见 slurm.conf(5) 手册页以获取完整的标志列表。环境变量优先于 slurm.conf 中的设置。
-
- SLURM_EXIT_ERROR
- 指定发生 Slurm 错误时生成的退出代码（例如，选项无效）。这可以被脚本用来区分应用程序退出代码和各种 Slurm 错误条件。另请参见 SLURM_EXIT_IMMEDIATE。
-
- SLURM_EXIT_IMMEDIATE
- 指定使用 --immediate 选项且当前没有可用资源时生成的退出代码。可以被脚本用来区分应用程序退出代码和各种 Slurm 错误条件。另请参见 SLURM_EXIT_ERROR。
-
输出环境变量
salloc 将在执行程序的环境中设置以下环境变量：
- SLURM_*_HET_GROUP_#
- 对于异构作业分配，环境变量为每个组件单独设置。
-
- SLURM_CLUSTER_NAME
- 作业执行所在集群的名称。
-
- SLURM_CONTAINER
- 作业的 OCI 包。仅在指定 --container 时设置。
-
- SLURM_CONTAINER_ID
- 作业的 OCI ID。仅在指定 --container-id 时设置。
-
- SLURM_CPUS_PER_GPU
- 每个分配的 GPU 请求的 CPU 数量。仅在指定 --cpus-per-gpu 选项时设置。
-
- SLURM_CPUS_PER_TASK
- 每个任务请求的 CPU 数量。仅在指定 --cpus-per-task 选项或 --tres-per-task=cpu=# 选项时设置。
-
- SLURM_DIST_PLANESIZE
- 平面分布大小。仅在平面分布中设置。请参见 -m, --distribution。
-
- SLURM_DISTRIBUTION
- 仅在指定 -m, --distribution 选项时设置。
-
- SLURM_GPU_BIND
- 请求将任务绑定到 GPU。仅在指定 --gpu-bind 选项时设置。
-
- SLURM_GPU_FREQ
- 请求的 GPU 频率。仅在指定 --gpu-freq 选项时设置。
-
- SLURM_GPUS
- 请求的 GPU 数量。仅在指定 -G, --gpus 选项时设置。
-
- SLURM_GPUS_PER_NODE
- 每个分配节点请求的 GPU 数量。仅在指定 --gpus-per-node 选项时设置。
-
- SLURM_GPUS_PER_SOCKET
- 每个分配插槽请求的 GPU 数量。仅在指定 --gpus-per-socket 选项时设置。
-
- SLURM_HET_SIZE
- 设置为异构作业中的组件数量。
-
- SLURM_JOB_ACCOUNT
- 与作业分配相关联的账户名称。
-
- SLURM_JOB_CPUS_PER_NODE
- 在分配的节点上可用于作业的 CPU 数量，使用格式 CPU_count[(xnumber_of_nodes)][,CPU_count[(xnumber_of_nodes)] ...]。例如：SLURM_JOB_CPUS_PER_NODE='72(x2),36' 表示在第一个和第二个节点（如 SLURM_JOB_NODELIST 所列）上分配有 72 个 CPU，而第三个节点上有 36 个 CPU。注意：select/linear 插件将整个节点分配给作业，因此该值表示分配节点上的 CPU 总数。select/cons_tres 插件将单个 CPU 分配给作业，因此该数字表示分配给作业的 CPU 数量。
-
- SLURM_JOB_END_TIME
- 作业预计结束时间的 UNIX 时间戳。
-
- SLURM_JOB_GPUS
- 分配给此作业的 GPU 的全局 GPU ID。GPU ID 与任何设备 cgroup 无关，即使设备受到任务/cgroup 的约束。仅在批处理和交互式作业中设置。
-
- SLURM_JOB_ID
- 作业分配的 ID。
-
- SLURM_JOB_LICENSES
- 请求的任何许可证的名称和数量。
-
- SLURM_JOB_NODELIST
- 分配给作业的节点列表。
-
- SLURM_JOB_NUM_NODES
- 作业分配中的节点总数。
-
- SLURM_JOB_PARTITION
- 作业运行的分区名称。
-
- SLURM_JOB_QOS
- 作业分配的服务质量（QOS）。
-
- SLURM_JOB_RESERVATION
- 包含作业分配的高级预留（如果有）。
-
- SLURM_JOB_START_TIME
- 作业开始时间的 UNIX 时间戳。
-
- SLURM_JOBID
- 作业分配的 ID。请参见 SLURM_JOB_ID。为了向后兼容而包含。
-
- SLURM_MEM_BIND
- 设置为 --mem-bind 选项的值。
-
- SLURM_MEM_BIND_LIST
- 设置为用于内存绑定的位掩码。
-
- SLURM_MEM_BIND_PREFER
- 如果 --mem-bind 选项包含 prefer 选项，则设置为“prefer”。
-
- SLURM_MEM_BIND_SORT
- 对空闲缓存页面进行排序（在 Intel KNL 节点上运行 zonesort）
-
- SLURM_MEM_BIND_TYPE
- 设置为使用 --mem-bind 选项指定的内存绑定类型。可能的值为“none”、“rank”、“map_map”、“mask_mem”和“local”。
-
- SLURM_MEM_BIND_VERBOSE
- 如果 --mem-bind 选项包含 verbose 选项，则设置为“verbose”。否则设置为“quiet”。
-
- SLURM_MEM_PER_CPU
- 与 --mem-per-cpu 相同
-
- SLURM_MEM_PER_GPU
- 每个分配的 GPU 请求的内存。仅在指定 --mem-per-gpu 选项时设置。
-
- SLURM_MEM_PER_NODE
- 与 --mem 相同
-
- SLURM_NNODES
- 作业分配中的节点总数。请参见 SLURM_JOB_NUM_NODES。为了向后兼容而包含。
-
- SLURM_NODELIST
- 分配给作业的节点列表。请参见 SLURM_JOB_NODELIST。为了向后兼容而包含。
-
- SLURM_NPROCS
- 与 SLURM_NTASKS 相同。为了向后兼容而包含。
-
- SLURM_NTASKS
- 如果指定了 --ntasks 选项，则设置为该值。或者，如果指定了任何 --ntasks-per-* 选项，则设置为作业中的任务数量。
注意：这也是 srun 的输入变量，因此如果设置，它将在从 salloc shell 调用 srun 时有效地设置 --ntasks 选项。
-
- SLURM_NTASKS_PER_CORE
- 如果指定了 --ntasks-per-core 选项，则设置为该值。
-
- SLURM_NTASKS_PER_GPU
- 如果指定了 --ntasks-per-gpu 选项，则设置为该值。
-
- SLURM_NTASKS_PER_NODE
- 如果指定了 --ntasks-per-node 选项，则设置为该值。
-
- SLURM_NTASKS_PER_SOCKET
- 如果指定了 --ntasks-per-socket 选项，则设置为该值。
-
- SLURM_OOMKILLSTEP
- 与 --oom-kill-step 相同
-
- SLURM_OVERCOMMIT
- 如果指定了 --overcommit，则设置为 1。
-
- SLURM_PROFILE
- 与 --profile 相同
-
- SLURM_SHARDS_ON_NODE
- 此节点上可用于步骤的 GPU 分片数量。
-
- SLURM_SUBMIT_DIR
- 从中调用 salloc 的目录，或者（如适用）由 -D, --chdir 选项指定的目录。
-
- SLURM_SUBMIT_HOST
- 从中调用 salloc 的计算机的主机名。
-
- SLURM_TASKS_PER_NODE
- 每个节点上要启动的任务数量。值用逗号分隔，顺序与 SLURM_JOB_NODELIST 中相同。如果两个或更多连续节点的任务数量相同，则该数量后跟“(x#)”，其中“#”是重复计数。例如，“SLURM_TASKS_PER_NODE=2(x3),1”表示前 3 个节点将各自执行两个任务，而第四个节点将执行一个任务。
-
- SLURM_THREADS_PER_CORE
- 仅在指定了 --threads-per-core 或 SALLOC_THREADS_PER_CORE 时设置。该值将设置为 --threads-per-core 或 SALLOC_THREADS_PER_CORE 指定的值。此值在作业分配内的后续 srun 调用中使用。
-
- SLURM_TRES_PER_TASK
- 设置为 --tres-per-task 的值。如果指定了 --cpus-per-task 或 --gpus-per-task，它也会在 SLURM_TRES_PER_TASK 中设置，就好像它是在 --tres-per-task 中指定的。
-
信号
当 salloc 等待 PENDING 作业分配时，大多数信号将导致 salloc 撤销分配请求并退出。
但是，如果分配已被授予并且 salloc 已经启动了指定的命令，则 salloc 将忽略大多数信号。salloc 不会退出或释放分配，直到命令退出。一个显著的例外是 SIGHUP。SIGHUP 信号将导致 salloc 释放分配并退出，而不等待命令完成。另一个例外是 SIGTERM，它将被转发到生成的进程。
示例
- 获取分配，并打开一个新的 xterm，在其中可以交互式输入 srun 命令：
-
$ salloc -N16 xterm salloc: 授予作业分配 65537 # （此时 xterm 出现，salloc 等待 xterm 退出） salloc: 放弃作业分配 65537
- 在一行命令中获取节点的分配并启动并行应用程序：
-
$ salloc -N5 srun -n10 myprogram
- 创建一个具有 3 个组件的异构作业，每个组件分配一组唯一的节点：
-
$ salloc -w node[2-3] : -w node4 : -w node[5-7] bash salloc: 作业 32294 排队并等待资源 salloc: 作业 32294 已分配资源 salloc: 授予作业分配 32294
版权
版权所有 (C) 2006-2007 加州大学理事会。 在劳伦斯利弗莫尔国家实验室制作（参见免责声明）。版权所有 (C) 2008-2010 劳伦斯利弗莫尔国家安全。
版权所有 (C) 2010-2022 SchedMD LLC。
该文件是 Slurm 的一部分，一个资源管理程序。 有关详细信息，请参见 <https://slurm.schedmd.com/>。
Slurm 是自由软件；您可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它；许可证的第 2 版，或（根据您的选择）任何后续版本。
Slurm 的分发是希望它能有用，但不提供任何担保；甚至没有对适销性或特定用途的隐含担保。有关更多详细信息，请参见 GNU 通用公共许可证。
另见
sinfo(1), sattach(1), sbatch(1), squeue(1), scancel(1), scontrol(1), slurm.conf(5), sched_setaffinity (2), numa (3)
索引
该文档由 man2html 使用手册页创建。
时间：2025年7月2日 13:21:56 GMT