资源限制

在使用本文件之前，强烈建议熟悉 Slurm 的 会计 网页。

层次结构

Slurm 的层次限制按以下顺序强制执行，其中作业 QOS 和分区 QOS 的顺序可以通过使用 QOS 标志 'OverPartQOS' 进行反转：

1. 分区 QOS 限制
2. 作业 QOS 限制
3. 用户关联
4. 账户关联，按层次递增
5. 根/集群关联
6. 分区限制
7. 无

注意：如果在此层次结构的多个点定义了限制，则将使用此列表中首次定义限制的点。考虑以下示例：

• MaxJobs=20，且在分区 QOS 中未定义 MaxSubmitJobs
• 作业 QOS 中未设置限制，且
• 用户关联中 MaxJobs=4 和 MaxSubmitJobs=50

生效的限制将是 MaxJobs=20 和 MaxSubmitJobs=50。

注意：上述优先顺序在以下限制中得到遵守：Max[Time|Wall]，[Min|Max]Nodes。对于这些限制，即使作业受到 QOS 和/或关联限制的强制执行，也不能超过分区级别施加的限制，即使它在列表的底部。因此，这三种类型的限制的默认值是由分区限制上限的。如果设置了相应的 QOS PartitionTimeLimit 和/或 Partition[Max|Min]Nodes 标志，则可以忽略此分区级别的限制，此时作业将受到 QOS 和/或关联级别施加的限制的强制执行，遵循上述顺序。Grp* 限制也是一个例外。在账户级别施加的更严格的限制将在用户级别施加的较宽松的限制之前强制执行。这是由于施加限制的性质，要求最高级别的限制不得被超越。

配置

调度策略信息必须存储在数据库中，具体由 AccountingStorageType 配置参数在 slurm.conf 配置文件中指定。信息可以记录在 MySQL 或 MariaDB 数据库中。出于安全和性能原因，强烈建议使用 SlurmDBD（Slurm 数据库守护进程）作为数据库的前端。SlurmDBD 使用 Slurm 身份验证插件（例如 MUNGE）。SlurmDBD 还使用现有的 Slurm 会计存储插件以最大化代码重用。SlurmDBD 使用数据缓存和待处理请求的优先级来优化性能。虽然 SlurmDBD 依赖于现有的 Slurm 插件进行身份验证和数据库使用，但在安装 SlurmDBD 的主机上不需要其他 Slurm 命令和守护进程。仅需要 slurmdbd 和 slurm-plugins RPM 以执行 SlurmDBD。

会计和调度策略都是基于 关联 配置的。关联 是一个 4 元组，由集群名称、银行账户、用户和（可选）Slurm 分区组成。为了强制执行调度策略，请设置 AccountingStorageEnforce 的值。此选项包含您可能希望强制执行的以逗号分隔的选项列表。有效选项包括：

• associations - 如果用户的 关联 不在数据库中，则这将阻止用户运行作业。此选项将阻止用户访问无效账户。
• limits - 这将强制执行设置给关联的限制。通过设置此选项，'associations' 选项也将被设置。
• qos - 这将要求所有作业指定（无论是明确还是默认）有效的 qos（服务质量）。每个关联在数据库中定义了 QOS 值。通过设置此选项，'associations' 选项也将被设置。
• safe - 这将确保只有在使用具有 TRES-分钟限制的关联或 qos 时，作业才能启动，如果作业能够运行到完成。未设置此选项时，只要其使用未达到 TRES-分钟限制，作业将被启动，这可能导致作业被启动但在达到限制时被终止。设置 'safe' 选项时，即使在作业启动后更改限制，作业也不会因限制而被终止，即使关联或 qos 违反了更新后的限制。通过设置此选项，'associations' 选项和 'limits' 选项也会自动设置。
• wckeys - 这将阻止用户在他们没有访问权限的 wckey 下运行作业。使用此选项时，'associations' 选项也将被设置。'TrackWCKey' 选项也将设置为 true。

注意：关联是集群、账户、用户名和可选分区名称的组合。
如果未设置 AccountingStorageEnforce（默认行为），作业将根据在每个集群中配置的 Slurm 策略执行。

工具

用于管理会计策略的工具是 sacctmgr。它可以用于创建和删除集群、用户、银行账户和分区记录以及它们的组合 关联 记录。有关此工具的详细信息和使用示例，请参见 man sacctmgr。

对调度策略所做的更改将立即上传到各个集群上的 Slurm 控制守护进程并生效。当删除关联时，所有属于该关联的正在运行或待处理作业将立即被取消。当降低限制时，正在运行的作业不会被取消以满足新限制，但将强制执行新的较低限制。

特定于关联的限制和调度策略

这些表示与关联相关的限制和调度策略。在处理关联时，大多数这些限制不仅适用于用户关联，还适用于每个集群和账户。限制和策略按以下顺序应用：
1. 指定给用户关联的选项。
2. 指定给账户的选项。
3. 指定给集群的选项。
4. 如果在上述级别未配置任何内容，则不应用限制。

这些只是关联的限制和策略。有关可显示的列的更完整描述，请参见 sacctmgr 手册页。

公平共享

用于确定优先级的整数值。基本上，这是该关联及其子级对上述系统的索取量。当在用户上使用时，可以是字符串 "parent"，这意味着父关联用于公平共享。如果在账户上设置 Fairshare=parent，则该账户的子级将在公平共享计算中有效地重新归属给其父级的第一个不是 Fairshare=parent 的父级。限制保持不变，仅其公平共享值受到影响。

GrpJobs

来自一个关联及其子级在任何给定时间能够运行的作业总数。如果达到此限制，则新作业将被排队，但仅在该组的先前作业完成后才能运行。

GrpJobsAccrue

来自一个关联及其子级在任何给定时间能够积累年龄优先级的待处理作业总数。如果达到此限制，则新作业将被排队，但在该组的先前作业从待处理状态移除之前不会积累年龄优先级。此限制并不决定作业是否可以运行，它仅限制优先级的年龄因素。

GrpSubmitJobs

来自一个关联及其子级在任何给定时间能够提交给系统的作业总数。如果达到此限制，则新提交请求将被拒绝，直到该组的先前作业完成。

GrpTRES

来自一个关联及其子级在任何给定时间能够使用的 TRES 总数。如果达到此限制，则新作业将被排队，但仅在该组释放资源后才能运行。

GrpTRESMins

来自一个关联及其子级过去、现在和未来的作业可能使用的 TRES 分钟总数。如果达到任何限制，则该组中所有使用该 TRES 的正在运行作业将被终止，并且不允许新作业运行。此使用量会衰减（衰减速率为 PriorityDecayHalfLife）。它还可以重置（根据 PriorityUsageResetPeriod）以允许作业再次对关联树运行。此限制仅在使用优先级多因素插件时适用。

GrpTRESRunMins

用于限制与关联及其子级一起运行的所有作业使用的 TRES 分钟的总数。这考虑了正在运行作业的时间限制并消耗它。如果达到限制，则在其他作业完成之前不会启动新作业，以释放时间。

GrpWall

正在运行的作业能够在关联及其子级中总共分配的最大墙钟时间。如果达到此限制，则该关联中的未来作业将被排队，直到它们能够在限制内运行。此使用量会衰减（衰减速率为 PriorityDecayHalfLife）。它还可以重置（根据 PriorityUsageResetPeriod）以允许作业再次对关联树运行。

MaxJobs

给定关联在任何给定时间能够运行的作业总数。如果达到此限制，则新作业将被排队，但仅在该关联中的现有作业完成后才能运行。

MaxJobsAccrue

给定关联在任何给定时间能够积累年龄优先级的最大待处理作业数。如果达到此限制，则新作业将被排队，但在该关联中的现有作业从待处理状态移除之前不会积累年龄优先级。此限制并不决定作业是否可以运行，它仅限制优先级的年龄因素。

MaxSubmitJobs

给定关联在任何给定时间能够提交给系统的最大作业数。如果达到此限制，则新提交请求将被拒绝，直到该关联中的现有作业完成。

MaxTRESMinsPerJob

每个作业可使用的 TRES 分钟限制。如果达到此限制，作业将在非安全模式下运行时被终止，否则作业将挂起，直到给予足够的时间来完成作业。

MaxTRESPerJob

每个作业可以从关联中获得的 TRES 最大数量。

MaxTRESPerNode

每个作业分配中每个节点可以使用的 TRES 最大数量。

MaxWallDurationPerJob

给定关联中任何单个作业能够运行的最大墙钟时间。如果达到此限制，作业将在提交时被拒绝。

MinPrioThreshold

在给定关联中预留资源所需的最低优先级。用于覆盖 bf_min_prio_reserve。有关详细信息，请参见 bf_min_prio_reserve。

QOS

关联能够运行的 QOS 的以逗号分隔的列表。

注意：在使用 sacctmgr 修改 TRES 字段时，必须指定要修改的 TRES（请参见 TRES 的完整列表），如下示例所示：

SET:
sacctmgr modify user bob set GrpTRES=cpu=1500,mem=200,gres/gpu=50
UNSET:
sacctmgr modify user bob set GrpTRES=cpu=-1,mem=-1,gres/gpu=-1

特定于 QOS 的限制和调度策略

如上所述，默认行为是设置在分区 QOS 上的限制将在作业请求的 QOS 上应用。您可以使用 OverPartQOS 标志更改此行为。

除非另有说明，如果作业请求超出其自身的给定限制，则作业将挂起，除非作业的 QOS 设置了 DenyOnLimit 标志，这将导致作业在提交时被拒绝。当考虑与此标志相关的 Grp 限制时，Grp 限制被视为最大限制。

GraceTime

预占宽限时间，格式为 <hh>:<mm>:<ss>，将延长给已选择进行预占的作业。默认值为零，表示此 QOS 不允许预占宽限时间。此值仅对 QOS PreemptMode=CANCEL 和 PreemptMode=REQUEUE 有意义。

GrpJobs

来自一个 QOS 在任何给定时间能够运行的作业总数。如果达到此限制，则新作业将被排队，但仅在该组的先前作业完成后才能运行。

GrpJobsAccrue

来自一个 QOS 在任何给定时间能够积累年龄优先级的待处理作业总数。如果达到此限制，则新作业将被排队，但在该组的先前作业从待处理状态移除之前不会积累年龄优先级。此限制并不决定作业是否可以运行，它仅限制优先级的年龄因素。此限制仅适用于作业的 QOS，而不适用于分区的 QOS。

GrpSubmitJobs

来自一个 QOS 在任何给定时间能够提交给系统的作业总数。如果达到此限制，则新提交请求将被拒绝，直到该组的先前作业完成。

GrpTRES

来自一个 QOS 在任何给定时间能够使用的 TRES 总数。如果达到此限制，则新作业将被排队，但仅在该组释放资源后才能运行。

GrpTRESMins

来自一个 QOS 过去、现在和未来的作业可能使用的 TRES 分钟总数。如果达到任何限制，则该组中所有使用该 TRES 的正在运行作业将被终止，并且不允许新作业运行。此使用量会衰减（衰减速率为 PriorityDecayHalfLife）。它还可以重置（根据 PriorityUsageResetPeriod）以允许作业再次对 QOS 运行。具有 NoDecay 标志的 QOS 不会衰减 GrpTRESMins，详细信息请参见 QOS 选项。此限制仅在使用优先级多因素插件时适用。

GrpTRESRunMins

用于限制与 QOS 一起运行的所有作业使用的 TRES 分钟的总数。这考虑了正在运行作业的时间限制并消耗它。如果达到限制，则在其他作业完成之前不会启动新作业，以释放时间。

GrpWall

正在运行的作业能够在 QOS 中总共分配的最大墙钟时间。如果达到此限制，则该 QOS 中的未来作业将被排队，直到它们能够在限制内运行。此使用量会衰减（衰减速率为 PriorityDecayHalfLife）。它还可以重置（根据 PriorityUsageResetPeriod）以允许作业再次对 QOS 运行。具有 NoDecay 标志的 QOS 不会衰减 GrpWall。有关详细信息，请参见 QOS 选项。

LimitFactor

一个浮点数，计入关联的 [Grp|Max]TRES 限制。例如，如果 LimitFactor 为 2，则在此 QOS 下运行的关联的 GrpTRES 为 30 个 CPU 时，将允许分配 60 个 CPU。 注意：此因子仅适用于在此 QOS 下运行的关联，不适用于 QOS 本身的任何限制。

MaxJobsAccruePerAccount

一个账户（或子账户）在任何给定时间能够积累年龄优先级的最大待处理作业数。此限制并不决定作业是否可以运行，它仅限制优先级的年龄因素。

MaxJobsAccruePerUser

一个用户在任何给定时间能够积累年龄优先级的最大待处理作业数。此限制并不决定作业是否可以运行，它仅限制优先级的年龄因素。

MaxJobsPerAccount

一个账户（或子账户）在任何给定时间能够运行的最大作业数。

MaxJobsPerUser

一个用户在任何给定时间能够运行的最大作业数。

MaxSubmitJobsPerAccount

一个账户（或子账户）在任何给定时间能够运行和待处理的最大作业数。

MaxSubmitJobsPerUser

一个用户在任何给定时间能够运行和待处理的最大作业数。

MaxTRESMinsPerJob

每个作业能够使用的 TRES 分钟的最大数量。

MaxTRESPerAccount

一个账户在任何给定时间能够分配的最大 TRES 数量。

MaxTRESPerJob

每个作业能够使用的最大 TRES 数量。

MaxTRESPerNode

每个作业分配中每个节点能够使用的最大 TRES 数量。

MaxTRESPerUser

一个用户在任何给定时间能够分配的最大 TRES 数量。

MaxWallDurationPerJob

每个作业能够使用的最大墙钟时间。格式为 <min> 或 <min>:<sec> 或 <hr>:<min>:<sec> 或 <days>-<hr>:<min>:<sec> 或 <days>-<hr>。该值以分钟记录，并根据需要进行四舍五入。

MinPrioThreshold

调度时预留资源所需的最低优先级。

MinTRESPerJob

使用请求的 QOS 时，任何给定作业的 TRES 最小大小。

UsageFactor

一个浮点数，计入作业的 TRES 使用（例如，RawUsage、TRESMins、TRESRunMins）。例如，如果使用因子为 2，则作业运行每个 TRESBillingUnit 秒将计为 2。如果使用因子为 0.5，则每秒仅计为一半的时间。设置为 0 将不会增加作业的时间使用。 使用因子仅适用于作业的 QOS，而不适用于分区 QOS。
如果设置了 UsageFactorSafe 标志，并且 AccountingStorageEnforce 包含 Safe，则作业只能在能够完成的情况下运行，并且不会因限制而被终止。
如果未设置 UsageFactorSafe 标志，并且 AccountingStorageEnforce 包含 Safe，则作业将在不应用使用因子的情况下进行调度，并且不会因限制而被终止。
如果未设置 UsageFactorSafe 标志，并且 AccountingStorageEnforce 不包含 Safe，则只要未达到限制，作业将被调度，但可能会因限制而被终止。
有关详细信息，请参见 AccountingStorageEnforce 在 slurm.conf 手册页中。

MaxNodes 和 MaxTime 选项已经在 Slurm 的每个分区配置中存在，但上述选项提供了按用户施加限制的能力。MaxJobs 选项为 Slurm 控制任何个人在集群上施加的工作负载提供了一种全新的机制，以实现用户之间的某种平衡。

在为分区 QOS 指定使用的 QOS 限制时，请记住这些限制是在 QOS 级别强制执行的，而不是单独针对每个分区。例如，如果 QOS 定义了 GrpTRES=cpu=20 限制，并且该 QOS 被分配给两个唯一的分区，则用户将被限制为 20 个 CPU，而不是每个分区允许 20 个 CPU。

公平共享调度基于 Slurm 数据库中维护的层次银行账户数据。有关更多信息，请参见 优先级/多因素 插件描述。

GRES 的特定限制

当 GRES 具有相关类型并且对该特定类型应用限制（例如 MaxTRESPerUser=gres/gpu:tesla=1）时，如果用户请求通用 GRES，则该类型的限制将不会被强制执行。在这种情况下，额外的 lua 作业提交插件检查用户请求可能会变得有用。例如，如果请求 --gres=gpu:2，并且设置了 MaxTRESPerUser=gres/gpu:tesla=1 的限制，则该限制将不会被强制执行，因此仍然可以获得两个 tesla。

这是由于设计限制。强制执行此类限制的唯一方法是将限制的规范与一个作业提交插件结合在一起，强制用户始终请求特定类型的模型。

基本 lua 作业提交插件函数的示例可能是：

function slurm_job_submit(job_desc, part_list, submit_uid)
   gres_request = ""
   t = {job_desc.tres_per_job,
	job_desc.tres_per_socket,
	job_desc.tres_per_task,
	job_desc.tres_per_node}
   for k in pairs(t) do
	gres_request = gres_request .. t[k] .. ","
   end
   if (gres_request ~= nil)
   then
      for g in gres_request:gmatch("[^,]+")
      do
	 bad = string.match(g,'^gres/gpu[:=]*[0-9]*$')
	 if (bad ~= nil)
	 then
	    slurm.log_info("用户指定了没有类型的 gpu GRES: %s", bad)
	    slurm.user_msg("请求 gpu GRES 时必须始终指定类型")
	    return slurm.ERROR
	 end
      end
   end
end

拥有此脚本和限制将强制用户始终指定带有类型的 gpu，从而强制每个特定模型的限制。

当为分区定义 TRESBillingWeights 时，应该包括类型和非类型资源。例如，如果您在一个分区中有 'tesla' GPU，并且仅为 'tesla' 类型的 GPU 资源定义了计费权重，则这些权重将不会应用于通用 GPU。

同样建议为通用和特定 GRES 类型设置 AccountingStorageTRES，否则请求通用实例的 GRES 将不会被计入。例如，要跟踪通用 GPU 和 Tesla GPU，您可以在 slurm.conf 中设置：

  AccountingStorageTRES=gres/gpu,gres/gpu:tesla

有关详细信息，请参见 可跟踪资源 TRES。

作业原因代码

当调度程序评估待处理作业但发现其超过配置的资源限制时，将为作业分配相应的原因。有关更多详细信息，请参见 作业原因代码 页面。有关调度的更多详细信息，请参见 调度配置指南。

最后修改于 2024 年 9 月 27 日