sbatch
部分: Slurm 命令 (1)更新: Slurm 命令
索引
名称
sbatch - 提交批处理脚本到 Slurm。概要
sbatch [选项(0)...] [ : [选项(N)...]] 脚本(0) [参数(0)...]
选项定义了在共同调度的异构作业中的多个作业。
有关异构作业的更多详细信息,请参见文档
https://slurm.schedmd.com/heterogeneous_jobs.html
描述
sbatch 将批处理脚本提交到 Slurm。批处理脚本可以通过命令行上的文件名传递给 sbatch,或者如果未指定文件名,sbatch 将从标准输入读取脚本。批处理脚本可以包含一行或多行以 "#SBATCH" 开头,后面跟着本页面上记录的任何 CLI 选项。#SBATCH 指令由 Slurm 直接读取,因此包括变量名在内的特定于 shell 的语法将被视为字面文本。一旦到达脚本中的第一行非注释、非空白行,将不再处理更多的 #SBATCH 指令。请参见下面的示例。
sbatch 在脚本成功传输到 Slurm 控制器并分配了 Slurm 作业 ID 后立即退出。批处理脚本不一定会立即获得资源,它可能会在待处理作业的队列中等待一段时间,直到所需资源可用。
默认情况下,标准输出和标准错误都被定向到名为 "slurm-%j.out" 的文件,其中 "%j" 被替换为作业分配号。该文件将在作业分配的第一个节点上生成。除了批处理脚本本身,Slurm 不会移动用户文件。
当作业分配最终授予批处理脚本时,Slurm 在分配节点的第一个节点上运行批处理脚本的单个副本。
以下文档描述了各种选项对作业和任务的 CPU 分配的影响。
https://slurm.schedmd.com/cpu_management.html
返回值
sbatch 成功时返回 0,失败时返回错误代码。脚本路径解析
批处理脚本按以下顺序解析:
1. 如果脚本以 "." 开头,则路径构造为:
当前工作目录 / 脚本
2. 如果脚本以 "/" 开头,则路径被视为绝对路径。
3. 如果脚本在当前工作目录中。
4. 如果脚本可以通过 PATH 解析。请参见 path_resolution(7)。
当前工作目录是调用进程的工作目录,除非传递了 --chdir 参数,这将覆盖当前工作目录。
选项
- -A, --account=<账户>
- 将此作业使用的资源计费到指定账户。 账户 是一个任意字符串。作业提交后,可以使用 scontrol 命令更改账户名称。
-
- --acctg-freq=<数据类型>=<间隔>[,<数据类型>=<间隔>...]
- 定义作业计费和分析采样间隔(以秒为单位)。 这可以用来覆盖 slurm.conf 文件中的 JobAcctGatherFrequency 参数。<数据类型>=<间隔> 指定 jobacct_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]]。您还可以给出像 now + count time-units 的时间,其中时间单位可以是 seconds(默认)、minutes、hours、days 或 weeks,并且您可以告诉 Slurm 在今天运行作业,使用关键字 today,并在明天运行作业,使用关键字 tomorrow。 该值可以在作业提交后使用 scontrol 命令更改。 例如:
--begin=16:00 --begin=now+1hour --begin=now+60 (默认以秒为单位) --begin=2010-01-20T12:34:00
-
关于日期/时间规范的说明:
- 尽管代码允许 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,此选项可能隐式设置任务数(每个请求的线程一个任务)。
请求在计算节点上为此 sbatch 脚本内部的 srun 命令启动的作业步骤以某个请求的频率运行(如果可能)。
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
-d afterok:20:21?afterany:23这意味着任何条件(afterok:20 或 afterok:21 或 afterany:23)都足以释放作业。 许多作业可以共享相同的依赖关系,这些作业甚至可能属于不同的用户。该值可以在作业提交后使用 scontrol 命令更改。 允许在联合中对远程作业的依赖关系。 一旦作业依赖关系由于前一作业的终止状态而失败,即使前一作业重新排队并在后续执行中具有不同的终止状态,依赖作业将永远不会运行。
-
- after:job_id[[+time][:jobid[+time]...]]
- 在指定作业启动或取消后,经过作业启动或取消后的 'time'(以分钟为单位),此作业可以开始执行。如果未给出 'time',则在启动或取消后没有延迟。
-
- 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 文档。
-
第一个分配方法(任务在节点之间的分配):
- *
-
- 使用默认方法将任务分配到节点(块)。
-
- block
-
- 块分配方法将任务分配到节点,使得连续的任务共享一个节点。例如,考虑分配三个每个有两个 CPU 的节点。一个四任务的块分配请求将把这些任务分配到节点上,其中任务一和二在第一个节点,任务三在第二个节点,任务四在第三个节点。如果任务数量超过分配的节点数量,块分配是默认行为。
-
- cyclic
-
- 循环分配方法将任务分配到节点,使得连续的任务在连续的节点上分配(以轮询方式)。例如,考虑分配三个每个有两个 CPU 的节点。一个四任务的循环分配请求将把这些任务分配到节点上,其中任务一和四在第一个节点,任务二在第二个节点,任务三在第三个节点。 请注意,当 SelectType 为 select/cons_tres 时,可能不会在每个节点上分配相同数量的 CPU。任务分配将在所有尚未分配给任务的节点之间轮询。如果任务数量不大于分配的节点数量,则循环分配是默认行为。
-
- plane
-
- 任务以大小 <size> 的块进行分配。必须给出大小或设置 SLURM_DIST_PLANESIZE。分配给每个节点的任务数量与循环分配相同,但分配给每个节点的任务 ID 取决于平面大小。此选项不能与其他分配规范组合。 有关更多详细信息(包括示例和图表),请参阅 mc_support 文档和 https://slurm.schedmd.com/dist_plane.html
-
- arbitrary
-
- 任意分配方法将按照环境变量 SLURM_HOSTFILE 指定的文件中列出的顺序分配进程。如果列出了此变量,它将覆盖任何指定的其他方法。如果未设置,则默认方法为块。 主机文件必须至少包含请求的主机数量,并且每行一个或用逗号分隔。如果指定任务数量(-n, --ntasks=<number>),您的任务将在节点上按照文件的顺序布局。
注意: 作业分配中的任意分配选项仅控制分配给作业的节点,而不控制这些节点上 CPU 的分配。此选项主要用于控制 srun 命令中现有作业分配的作业步骤任务布局。
注意: 如果给定任务数量并且也给定请求的节点列表,则如果列表中的节点数量大于任务数量,则将使用该列表中的节点数量减少到与任务数量匹配。 - 任意分配方法将按照环境变量 SLURM_HOSTFILE 指定的文件中列出的顺序分配进程。如果列出了此变量,它将覆盖任何指定的其他方法。如果未设置,则默认方法为块。 主机文件必须至少包含请求的主机数量,并且每行一个或用逗号分隔。如果指定任务数量(-n, --ntasks=<number>),您的任务将在节点上按照文件的顺序布局。
-
第二个分配方法(在插槽之间分配 CPU 以进行绑定):
- *
-
- 使用默认方法在插槽之间分配 CPU(循环)。
-
- block
-
- 块分配方法将连续分配的 CPU 从同一插槽中分配给任务绑定,然后使用下一个连续的插槽。
-
- cyclic
-
- 循环分配方法将为给定任务绑定的分配 CPU 从同一插槽中连续分配,并从下一个连续的插槽中为下一个任务分配,以轮询方式在插槽之间分配。 需要多个 CPU 的任务将尽可能在单个插槽上分配所有这些 CPU。
注意: 在启用超线程的节点上,未请求完整核心的任务可能会在插槽之间分配。可以通过指定 --ntasks-per-core=1 来避免这种情况,这将强制任务分配完整的核心。 - 循环分配方法将为给定任务绑定的分配 CPU 从同一插槽中连续分配,并从下一个连续的插槽中为下一个任务分配,以轮询方式在插槽之间分配。 需要多个 CPU 的任务将尽可能在单个插槽上分配所有这些 CPU。
-
- fcyclic
-
- fcyclic 分配方法将为任务绑定分配的 CPU 从连续的插槽中以轮询方式分配。 需要多个 CPU 的任务将以循环方式在插槽之间分配每个 CPU。
-
第三个分配方法(在核心之间分配 CPU 以进行绑定):
- *
-
- 使用默认方法在核心之间分配 CPU(继承自第二个分配方法)。
-
- block
-
- 块分配方法将连续分配的 CPU 从同一核心中分配给任务绑定,然后使用下一个连续的核心。
-
- cyclic
-
- 循环分配方法将为给定任务绑定的分配 CPU 从同一核心中连续分配,并从下一个连续的核心为下一个任务分配,以轮询方式在核心之间分配。
-
- fcyclic
-
- fcyclic 分配方法将为任务绑定的分配 CPU 从连续的核心中以轮询方式分配。
-
可选控制任务在节点之间的分配:
- Pack
-
- 与其将作业步骤的任务均匀分配到其分配的节点上,不如尽可能紧密地将它们打包到节点上。 这仅在使用 "block" 任务分配方法时适用。
-
- NoPack
-
- 与其将作业步骤的任务尽可能紧密地打包到节点上,不如均匀分配它们。 此用户选项将优先于 SelectTypeParameters CR_Pack_Nodes 配置参数。
注意: 此选项与 --oversubscribe 是互斥的。
-
- --export=ALL
- 如果未指定 --export,则为默认模式。用户的所有环境将被加载(无论是来自调用者的环境还是如果指定了 --get-user-env 则来自干净环境)。
-
- --export=NIL
- 仅定义用户环境中的 SLURM_* 和 SPANK 选项变量。用户必须使用要执行的二进制文件的绝对路径来定义环境。
用户不能使用 "NIL" 指定显式环境变量。
与 NONE 不同,NIL 不会自动使用 --get-user-env 机制创建用户的环境。
-
- --export=NONE
- 仅定义用户环境中的 SLURM_* 和 SPANK 选项变量。用户必须使用要执行的二进制文件的绝对路径来定义环境。
用户不能使用 "NONE" 指定显式环境变量。
但是,Slurm 将隐式尝试在执行脚本的节点上加载用户的环境,就好像指定了 --get-user-env 一样。
此选项对于在一个集群上提交并在另一个集群上执行的作业特别重要(例如,具有不同路径)。 为了避免步骤继承环境导出设置(例如 "NONE"),作业脚本中的环境变量 SLURM_EXPORT_ENV 应设置为 "ALL"。
-
- --export=[ALL,]<environment_variables>
- 导出所有 SLURM_* 和 SPANK 选项环境变量以及显式定义的变量。多个环境变量名称应用逗号分隔。 环境变量名称可以指定以传播当前值(例如 "--export=EDITOR")或特定值可以被导出(例如 "--export=EDITOR=/bin/emacs")。如果指定了 "ALL",则将加载所有用户环境变量,并优先于任何显式给定的环境变量。
-
-
- 示例: --export=EDITOR,ARG1=test
- 在此示例中,传播的环境将仅包含用户环境中的变量 EDITOR、SLURM_* 环境变量和 ARG1=test。
-
- 示例: --export=ALL,EDITOR=/bin/emacs
- 此示例有两种可能的结果。如果调用者定义了 EDITOR 环境变量,则作业的环境将从调用者的环境中继承该变量。如果调用者没有为 EDITOR 定义环境变量,则作业的环境将使用 --export 给定的值。
-
注意: NONE 和 [ALL,]<environment_variables> 隐式地像定义了 --get-user-env 一样工作。请参见其各自部分的影响。
如果启用 SchedulerParameters=extra_constraints,则此字符串用于根据每个节点的 Extra 字段进行节点过滤。
注意: 这些选项不指定资源分配大小。 每个指定的值被视为最小值。 可以使用星号 (*) 作为占位符,表示要利用所有可用的该类型资源。值也可以指定为 min-max。如果需要,可以在单独的选项中指定各个级别:
--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),每个请求的线程一个任务。
注意: 显式或隐式使用 --get-user-env 依赖于能够创建 PID 和挂载命名空间的能力。强烈建议确保 PID 和挂载命名空间的创建是可用的且没有限制(检查 /proc/sys/user/max_[pid|mnt]_namespaces 不为 0)。虽然它们并不是 --get-user-env 工作的严格必要条件,但它们确保在检索环境后不会留下孤儿进程。
支持的 value 定义:
注意: 分配必须在每个节点上至少包含一个 GPU,或者如果使用类型,则每个节点上必须包含每种 GPU 类型的一个。使用异构作业,如果不同节点需要不同的 GPU 类型。
-
- multiple-tasks-per-sharing
-
- 否定 one-task-per-sharing。如果在 SelectTypeParameters 中默认设置了此选项,则此选项非常有用。
-
- disable-binding
-
- 否定 enforce-binding。如果在 SelectTypeParameters 中默认设置了此选项,则此选项非常有用。
-
- enforce-binding
-
- 作业可用的唯一 CPU 将是绑定到所选 GRES 的那些(即,在 gres.conf 文件中标识的 CPU 将被严格执行)。此选项可能导致作业启动延迟。 例如,要求两个 GPU 和一个 CPU 的作业将被延迟,直到单个插槽上的两个 GPU 可用,而不是使用绑定到不同插槽的 GPU,但是,由于改善了通信速度,应用程序性能可能会提高。 要求节点配置有多个插槽,并且资源过滤将在每个插槽的基础上执行。
注意: 此选项可以在 SelectTypeParameters 中默认设置。
注意: 此选项特定于 SelectType=cons_tres。
注意: 如果尝试在多个插槽上的多个 GRES 上强制绑定,此选项可能会产生未定义的结果。 - 作业可用的唯一 CPU 将是绑定到所选 GRES 的那些(即,在 gres.conf 文件中标识的 CPU 将被严格执行)。此选项可能导致作业启动延迟。 例如,要求两个 GPU 和一个 CPU 的作业将被延迟,直到单个插槽上的两个 GPU 可用,而不是使用绑定到不同插槽的 GPU,但是,由于改善了通信速度,应用程序性能可能会提高。 要求节点配置有多个插槽,并且资源过滤将在每个插槽的基础上执行。
-
- one-task-per-sharing
-
- 不允许不同任务从同一共享 GRES 中分配共享 GRES。
注意: 仅在请求共享 GRES 时使用 --tres-per-task 时强制执行此标志。
注意: 此选项可以在 SelectTypeParameters=ONE_TASK_PER_SHARING_GRES 中默认设置。
注意: 此选项特定于 SelectTypeParameters=MULTIPLE_SHARING_GRES_PJ - 不允许不同任务从同一共享 GRES 中分配共享 GRES。
注意: 此选项暗示某些相关选项的特定值,这会阻止与用户指定的 --ntasks-per-core、--threads-per-core 或 -B 一起使用。 这些冲突选项将在指定为命令行参数时覆盖 --hint。如果冲突选项作为环境变量指定,则命令行参数中的 --hint 将优先。
默认情况下,"/dev/null" 在批处理脚本的标准输入上打开,标准输出和标准错误都指向名为 "slurm-%j.out" 的文件,其中 "%j" 被作业分配号替换,如下面的 filename pattern 部分所述。
注意: 提交异构作业时,许可证请求只能在第一个组件作业上进行。 例如 "sbatch -L ansys:2 : script.sh"。
注意: 如果在 AccountingStorageTres 中跟踪许可证并且使用 OR,则 ReqTRES 将显示所有请求的 tres,以逗号分隔。AllocTRES 将仅显示分配给作业的许可证。
注意: 当作业请求 OR 的许可证时,Slurm 将尝试按请求的顺序分配许可证。此指定顺序将优先于即使在请求的保留上可以满足的其余请求的许可证。这也适用于当 SchedulerParameters=bf_licenses 配置时的回填计划。
除非指定 ARRAY_TASKS 选项,否则作业 BEGIN、END、FAIL 和 REQUEUE 的邮件通知适用于整个作业数组,而不是为作业数组中的每个任务生成单独的电子邮件消息。
注意: 内存大小规范为零被视为特殊情况,并授予作业访问每个节点上的所有内存。
注意: 每个 slurmstepd 进程使用的内存包含在作业的总内存使用中。它通常消耗 20MiB 到 200MiB 之间的内存,尽管这可能因系统配置和任何加载的插件而异。
注意: 除非 Slurm 配置为使用强制机制,否则内存请求将不会严格执行。有关更多详细信息,请参见 cgroup.conf(5)手册页中的 ConstrainRAMSpace 和 slurm.conf(5)手册页中的 OverMemoryKill。
注意: 要让 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* 变量的更详细描述,请参见 环境变量 部分。
支持的选项包括:
-
- help
-
- 显示此帮助信息
-
- local
-
- 使用与正在使用的处理器本地的内存
-
- 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 应分配给作业。
-
- no[ne]
-
- 不将任务绑定到内存(默认)
-
- p[refer]
-
- 优先使用第一个指定的 NUMA 节点,但允许
使用 其他 可用 NUMA 节点。 - 优先使用第一个指定的 NUMA 节点,但允许
-
- q[uiet]
-
- 在任务运行之前安静地绑定(默认)
-
- rank
-
- 按任务排名绑定(不推荐)
-
- sort
-
- 对空闲缓存页面进行排序(在 Intel KNL 节点上运行 zonesort)
-
- v[erbose]
-
- 显示详细信息
注意:如果作业请求的最终内存量 无法满足分区中配置的任何节点,则作业将被拒绝。 如果作业分配使用--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”以禁用SBATCH_NO_KILL环境变量的效果。
默认情况下,如果其分配的任何节点失败,Slurm将终止整个作业分配。
注意:如果将ForceRequeueOnFail设置为slurm.conf中的PrologFlags参数选项,则可以覆盖此设置。
注意:此选项不能与任意分配一起使用。
注意:在使用 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互斥。
有效的类型值包括:
注意:请求的节点计数必须始终能被请求的段大小整除。
注意:段大小必须小于或等于 计划的基础块大小。例如,对于基础块大小为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-per-task 的无效 TRES 包括 bb、billing、energy、fs、mem、node、pages、vmem。
-
- 0
- 在可以进行分配时立即开始执行。不要等待所有节点准备就绪(即启动)。
-
- 1
- 在所有节点准备就绪后再开始执行。
文件名模式
sbatch 允许文件名模式包含一个或多个替换符号,这些符号是一个百分号 "%" 后跟一个字母(例如 %j)。
放置在百分号字符和格式说明符之间的数字可以用于在 IO 文件名中将结果零填充到指定数字的最小值。如果格式说明符对应于非数字数据(例如 %N),则忽略此数字。最大数字为 10,如果使用大于 10 的值,则结果填充到 10 个字符。以下是格式字符串如何用于具有 JobID 为 128 和步骤 ID 为 0 的 4 个任务作业步骤的一些示例:
- job%J.out
- job128.0.out
-
- job%4j.out
- job0128.out
-
- job%2j-%2t.out
- job128-00.out, job128-01.out, ...
-
性能
执行 sbatch 会向 slurmctld 发送远程过程调用。如果来自 sbatch 或其他向 slurmctld 守护进程发送远程过程调用的 Slurm 客户端命令的调用足够多,可能会导致 slurmctld 守护进程的性能下降,可能导致服务拒绝。
请勿在 shell 脚本或其他程序的循环中运行 sbatch 或其他向 slurmctld 发送远程过程调用的 Slurm 客户端命令。确保程序将对 sbatch 的调用限制在收集信息所需的最小值。
输入环境变量
在启动时,sbatch 将读取并处理以下环境变量中设置的选项。这些变量中的大多数是以与上述选项相同的方式设置的。对于定义为不期望参数的标志选项,可以通过设置环境变量而不指定值(空字符串或 NULL 字符串)、字符串 'yes' 或非零数字来启用该选项。环境变量的任何其他值将导致该选项未被设置。以下是这些规则的一些例外情况。
注意: 环境变量将覆盖批处理脚本中设置的任何选项,而命令行选项将覆盖任何环境变量。
- SBATCH_ACCOUNT
- 与 -A, --account 相同
-
- SBATCH_ACCTG_FREQ
- 与 --acctg-freq 相同
-
- SBATCH_ARRAY_INX
- 与 -a, --array 相同
-
- SBATCH_BATCH
- 与 --batch 相同
-
- SBATCH_CLUSTERS 或 SLURM_CLUSTERS
- 与 --clusters 相同
-
- SBATCH_CONSTRAINT
- 与 -C, --constraint 相同
-
- SBATCH_CONTAINER
- 与 --container 相同。
-
- SBATCH_CONTAINER_ID
- 与 --container-id 相同。
-
- SBATCH_CORE_SPEC
- 与 --core-spec 相同
-
- SBATCH_CPUS_PER_GPU
- 与 --cpus-per-gpu 相同
-
- SBATCH_DEBUG
- 与 -v, --verbose 相同,当设置为 1 时,设置为 2 时给出 -vv,等等。
-
- SBATCH_DELAY_BOOT
- 与 --delay-boot 相同
-
- SBATCH_DISTRIBUTION
- 与 -m, --distribution 相同
-
- SBATCH_ERROR
- 与 -e, --error 相同
-
- SBATCH_EXCLUSIVE
- 与 --exclusive 相同
-
- SBATCH_EXPORT
- 与 --export 相同
-
- SBATCH_GET_USER_ENV
- 与 --get-user-env 相同
-
- SBATCH_GPU_BIND
- 与 --gpu-bind 相同
-
- SBATCH_GPU_FREQ
- 与 --gpu-freq 相同
-
- SBATCH_GPUS
- 与 -G, --gpus 相同
-
- SBATCH_GPUS_PER_NODE
- 与 --gpus-per-node 相同
-
- SBATCH_GPUS_PER_TASK
- 与 --gpus-per-task 相同
-
- SBATCH_GRES
- 与 --gres 相同
-
- SBATCH_GRES_FLAGS
- 与 --gres-flags 相同
-
- SBATCH_HINT 或 SLURM_HINT
- 与 --hint 相同
-
- SBATCH_IGNORE_PBS
- 与 --ignore-pbs 相同
-
- SBATCH_INPUT
- 与 -i, --input 相同
-
- SBATCH_JOB_NAME
- 与 -J, --job-name 相同
-
- SBATCH_MEM_BIND
- 与 --mem-bind 相同
-
- SBATCH_MEM_PER_CPU
- 与 --mem-per-cpu 相同
-
- SBATCH_MEM_PER_GPU
- 与 --mem-per-gpu 相同
-
- SBATCH_MEM_PER_NODE
- 与 --mem 相同
-
- SBATCH_NETWORK
- 与 --network 相同
-
- SBATCH_NO_KILL
- 与 -k, --no-kill 相同
-
- SBATCH_NO_REQUEUE
- 与 --no-requeue 相同
-
- SBATCH_OPEN_MODE
- 与 --open-mode 相同
-
- SBATCH_OUTPUT
- 与 -o, --output 相同
-
- SBATCH_OVERCOMMIT
- 与 -O, --overcommit 相同
-
- SBATCH_PARTITION
- 与 -p, --partition 相同
-
- SBATCH_POWER
- 与 --power 相同
-
- SBATCH_PROFILE
- 与 --profile 相同
-
- SBATCH_QOS
- 与 --qos 相同
-
- SBATCH_REQ_SWITCH
- 当使用树形拓扑时,这定义了作业分配所需的最大交换机数量,并可选地定义等待该数量交换机的最大时间。请参见 --switches
-
- SBATCH_REQUEUE
- 与 --requeue 相同
-
- SBATCH_RESERVATION
- 与 --reservation 相同
-
- SBATCH_SEGMENT_SIZE
- 与 --segment 相同
-
- SBATCH_SIGNAL
- 与 --signal 相同
-
- SBATCH_SPREAD_JOB
- 与 --spread-job 相同
-
- SBATCH_THREAD_SPEC
- 与 --thread-spec 相同
-
- SBATCH_THREADS_PER_CORE
- 与 --threads-per-core 相同
-
- SBATCH_TIMELIMIT
- 与 -t, --time 相同
-
- SBATCH_TRES_BIND
- 与 --tres-bind 相同
-
- SBATCH_TRES_PER_TASK
- 与 --tres-per-task 相同
-
- SBATCH_USE_MIN_NODES
- 与 --use-min-nodes 相同
-
- SBATCH_WAIT
- 与 -W, --wait 相同
-
- SBATCH_WAIT_ALL_NODES
- 与 --wait-all-nodes 相同。必须设置为 0 或 1 以禁用或启用该选项。
-
- SBATCH_WAIT4SWITCH
- 请求交换机的最大等待时间。请参见 --switches
-
- SBATCH_WCKEY
- 与 --wckey 相同
-
- SLURM_CONF
- Slurm 配置文件的位置。
-
- SLURM_DEBUG_FLAGS
- 指定 sbatch 使用的调试标志。有关完整的标志列表,请参见 slurm.conf(5) 手册页。环境变量优先于 slurm.conf 中的设置。
-
- SLURM_EXIT_ERROR
- 指定发生 Slurm 错误时生成的退出代码(例如,选项无效)。这可以被脚本用于区分应用程序退出代码和各种 Slurm 错误条件。
-
- SLURM_STEP_KILLED_MSG_NODE_ID=ID
- 如果设置,只有指定的节点将在作业或步骤被信号杀死时记录。
-
- SLURM_UMASK
- 如果定义,Slurm 将使用定义的 umask 在为作业创建输出/错误文件时设置权限。
-
输出环境变量
Slurm 控制器将在批处理脚本的环境中设置以下变量。
- SBATCH_MEM_BIND
- 设置为 --mem-bind 选项的值。
-
- SBATCH_MEM_BIND_LIST
- 设置为用于内存绑定的位掩码。
-
- SBATCH_MEM_BIND_PREFER
- 如果 --mem-bind 选项包含 prefer 选项,则设置为 "prefer"。
-
- SBATCH_MEM_BIND_TYPE
- 设置为与 --mem-bind 选项指定的内存绑定类型。可能的值为 "none"、"rank"、"map_map"、"mask_mem" 和 "local"。
-
- SBATCH_MEM_BIND_VERBOSE
- 如果 --mem-bind 选项包含 verbose 选项,则设置为 "verbose"。否则设置为 "quiet"。
-
- SLURM_*_HET_GROUP_#
- 对于异构作业分配,环境变量为每个组件单独设置。
-
- SLURM_ARRAY_JOB_ID
- 作业数组的主作业 ID 编号。
-
- SLURM_ARRAY_TASK_COUNT
- 作业数组中的任务总数。
-
- SLURM_ARRAY_TASK_ID
- 作业数组 ID(索引)编号。
-
- SLURM_ARRAY_TASK_MAX
- 作业数组的最大 ID(索引)编号。
-
- SLURM_ARRAY_TASK_MIN
- 作业数组的最小 ID(索引)编号。
-
- SLURM_ARRAY_TASK_STEP
- 作业数组的索引步长。
-
- SLURM_CLUSTER_NAME
- 作业正在执行的集群名称。
-
- SLURM_CPUS_ON_NODE
- 分配给批处理步骤的 CPU 数量。注意: select/linear 插件将整个节点分配给作业,因此该值表示节点上的 CPU 总数。对于 cons/tres 插件,此数字表示分配给步骤的此节点上的 CPU 数量。
-
- SLURM_CPUS_PER_GPU
- 每个分配的 GPU 请求的 CPU 数量。仅在指定了 --cpus-per-gpu 选项时设置。
-
- SLURM_CPUS_PER_TASK
- 每个任务请求的 CPU 数量。仅在指定了 --cpus-per-task 选项或 --tres-per-task=cpu=# 选项时设置。
-
- SLURM_CONTAINER
- 作业的 OCI 包。仅在指定了 --container 时设置。
-
- SLURM_CONTAINER_ID
- 作业的 OCI id。仅在指定了 --container-id 时设置。
-
- SLURM_DIST_PLANESIZE
- 平面分布大小。仅在平面分布时设置。请参见 -m, --distribution。
-
- SLURM_DISTRIBUTION
- 与 -m, --distribution 相同
-
- SLURM_EXPORT_ENV
- 与 --export 相同。
-
- SLURM_GPU_BIND
- 请求将任务绑定到 GPU。仅在指定了 --gpu-bind 选项时设置。
-
- SLURM_GPU_FREQ
- 请求的 GPU 频率。仅在指定了 --gpu-freq 选项时设置。
-
- SLURM_GPUS
- 请求的 GPU 数量。仅在指定了 -G, --gpus 选项时设置。
-
- SLURM_GPUS_ON_NODE
- 分配给批处理步骤的 GPU 数量。
-
- SLURM_GPUS_PER_NODE
- 每个分配节点请求的 GPU 数量。仅在指定了 --gpus-per-node 选项时设置。
-
- SLURM_GPUS_PER_SOCKET
- 每个分配插槽请求的 GPU 数量。仅在指定了 --gpus-per-socket 选项时设置。
-
- SLURM_GTIDS
- 在此节点上运行的全局任务 ID。零起始并用逗号分隔。如果 Slurm 是使用 pmi 支持构建的,则由 pmi 内部读取。保留该变量可能会在作业内部使用外部软件包时导致问题(已知 Abaqus 和 Ansys 在设置时存在问题 - 请查阅相关文档以获取第三方软件)。
-
- 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_DEPENDENCY
- 设置为--dependency选项的值。
-
- SLURM_JOB_END_TIME
- 作业预计结束时间的UNIX时间戳。
-
- SLURM_JOB_GPUS
- 分配给该作业的GPU的全局GPU ID。GPU ID与任何设备cgroup无关,即使设备受到任务/cgroup的约束。 仅在批处理和交互式作业中设置。
-
- SLURM_JOB_ID
- 作业分配的ID。
-
- SLURM_JOB_LICENSES
- 请求的任何许可证的名称和数量。
-
- SLURM_JOB_NAME
- 作业的名称。
-
- SLURM_JOB_NODELIST
- 分配给作业的节点列表。
-
- SLURM_JOB_NUM_NODES
- 作业资源分配中的节点总数。
-
- SLURM_JOB_PARTITION
- 作业运行的分区名称。
-
- SLURM_JOB_QOS
- 作业分配的服务质量(QOS)。
-
- SLURM_JOB_RESERVATION
- 包含作业分配的高级预留(如果有的话)。
-
- SLURM_JOB_SEGMENT_SIZE
- 用于创建作业分配的段大小。 仅在指定了--segment时设置。
-
- SLURM_JOB_START_TIME
- 作业开始时间的UNIX时间戳。
-
- SLURM_JOBID
- 作业分配的ID。参见SLURM_JOB_ID。为了向后兼容而包含。
-
- SLURM_LOCALID
- 作业中进程的节点本地任务ID。
-
- 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_NODEID
- 分配的节点ID。
-
- SLURM_NODELIST
- 分配给作业的节点列表。参见SLURM_JOB_NODELIST。为了向后兼容而包含。
-
- SLURM_NPROCS
- 与SLURM_NTASKS相同。为了向后兼容而包含。
-
- SLURM_NTASKS
- 如果指定了--ntasks选项,则设置为该值。或者,如果指定了任何--ntasks-per-*选项,则设置为作业中的任务数量。
注意:这也是srun的输入变量,因此如果设置,它将在从批处理脚本调用srun时有效地设置--ntasks选项。
-
- SLURM_NTASKS_PER_CORE
- 每个核心请求的任务数量。 仅在指定了--ntasks-per-core选项时设置。
-
- SLURM_NTASKS_PER_GPU
- 每个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_PRIO_PROCESS
- 作业提交时的调度优先级(nice值)。 该值会传播到生成的进程。
-
- SLURM_PROCID
- 当前进程的MPI等级(或相对进程ID)。
-
- SLURM_PROFILE
- 与--profile相同
-
- SLURM_RESTART_COUNT
- 如果作业因系统故障而重新启动或被显式重新排队,则此值将发送作业重新启动的次数。
-
- SLURM_SHARDS_ON_NODE
- 该节点上可用于步骤的GPU分片数量。
-
- SLURM_SUBMIT_DIR
- 从中调用sbatch的目录。
-
- SLURM_SUBMIT_HOST
- 从中调用sbatch的计算机的主机名。
-
- SLURM_TASK_PID
- 正在启动的任务的进程ID。
-
- SLURM_TASKS_PER_NODE
- 每个节点要启动的任务数量。值用逗号分隔,并与SLURM_JOB_NODELIST中的顺序相同。 如果两个或更多连续节点要有相同的任务数量,则该数量后跟“(x#)”,其中“#”是重复计数。例如,“SLURM_TASKS_PER_NODE=2(x3),1”表示前面三个节点将各执行两个任务,而第四个节点将执行一个任务。
-
- SLURM_THREADS_PER_CORE
- 仅在指定了--threads-per-core或SBATCH_THREADS_PER_CORE时设置。该值将设置为--threads-per-core或SBATCH_THREADS_PER_CORE指定的值。这在作业分配中的后续srun调用中使用。
-
- SLURM_TOPOLOGY_ADDR
- 仅在系统配置了拓扑/树插件时设置。该值将设置为可能参与作业通信的网络交换机的名称,从系统的顶级交换机到叶子交换机,最后到节点名称。每个硬件组件名称之间用句点分隔。
-
- SLURM_TOPOLOGY_ADDR_PATTERN
- 仅在系统配置了拓扑/树插件时设置。该值将设置为SLURM_TOPOLOGY_ADDR中列出的组件类型。每个组件将被标识为“switch”或“node”。每个硬件组件类型之间用句点分隔。
-
- SLURM_TRES_PER_TASK
- 设置为--tres-per-task的值。如果指定了--cpus-per-task或--gpus-per-task,它也会在SLURM_TRES_PER_TASK中设置,就好像它在--tres-per-task中指定一样。
-
- SLURMD_NODENAME
- 运行作业脚本的节点名称。
-
示例
- 通过命令行指定一个批处理脚本的文件名。该批处理脚本为作业指定了1分钟的时间限制。
-
$ cat myscript #!/bin/sh #SBATCH --time=1 srun hostname |sort $ sbatch -N4 myscript salloc: 授予作业分配 65537 $ cat slurm-65537.out host1 host2 host3 host4
- 将批处理脚本通过标准输入传递给sbatch:
-
$ sbatch -N4 <<EOF > #!/bin/sh > srun hostname |sort > EOF sbatch: 提交批处理作业 65541 $ cat slurm-65541.out host1 host2 host3 host4
- 创建一个包含3个组件的异构作业,每个组件分配一组独特的节点:
-
$ sbatch -w node[2-3] : -w node4 : -w node[5-7] work.bash 提交批处理作业 34987
版权
版权所有 (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),salloc(1),squeue(1),scancel(1),scontrol(1), slurm.conf(5),sched_setaffinity (2),numa (3)
索引
该文档由 man2html 使用手册页创建。
时间:2025年7月2日 13:21:56 GMT