Resource Limits

Familiarity with Slurm's Accounting web page is strongly recommended before use of this document.
このドキュメントを使用する前に、SlurmのアカウンティングWebページに精通していることを強くお勧めします。

Hierarchy

Slurm's hierarchical limits are enforced in the following order with Job QOS and Partition QOS order being reversible by using the QOS flag 'OverPartQOS':
Slurmの階層制限は、QOSフラグ 'OverPartQOS'を使用することでジョブQOSとパーティションQOSの順序を逆にできる次の順序で適用されます。

1. Partition QOS limit
   パーティションQOS制限
   
2. Job QOS limit
   ジョブのQOS制限
   
3. User association
   ユーザーの関連付け
   
4. Account association(s), ascending the hierarchy
   アカウントの関連付け、階層を昇順
   
5. Root/Cluster association
   ルート/クラスターの関連付け
   
6. Partition limit
   パーティション制限
   
7. None
   なし
   

Note: If limits are defined at multiple points in this hierarchy, the point in this list where the limit is first defined will be used. Consider the following example:
注：制限がこの階層の複数のポイントで定義されている場合、制限が最初に定義されているこのリストのポイントが使用されます。次の例を検討してください。

• MaxJobs=20 and MaxSubmitJobs is undefined in the partition QOS
  MaxJobs = 20であり、MaxSubmitJobsがパーティションQOSで定義されていません
  
• No limits are set in the job QOS and
  ジョブのQOSに制限は設定されていません。
  
• MaxJobs=4 and MaxSubmitJobs=50 in the user association
  ユーザーの関連付けでMaxJobs = 4およびMaxSubmitJobs = 50
  

The limits in effect will be MaxJobs=20 and MaxSubmitJobs=50.
有効な制限は、MaxJobs = 20およびMaxSubmitJobs = 50になります。

Note: The precedence order specified above is respected except for the following limits: Max[Time|Wall], [Min|Max]Nodes. For these limits, even if the job is enforced with QOS and/or Association limits, it can't go over the limit imposed at Partition level, even if it listed at the bottom. So the default for these 3 types of limits is that they are upper bound by the Partition one. This Partition level bound can be ignored if the respective QOS PartitionTimeLimit and/or Partition[Max|Min]Nodes flags are set, then the job would be enforced the limits imposed at QOS and/or association level respecting the order above.
注：上記の優先順位は、Max [Time | Wall]、[Min | Max] Nodesの制限を除いて順守されます。これらの制限については、ジョブがQOSやアソシエーションの制限で実施されている場合でも、下部にリストされていても、パーティションレベルで課された制限を超えることはできません。したがって、これら3つのタイプの制限のデフォルトは、パーティション1によって上限が設定されることです。それぞれのQOS PartitionTimeLimitおよび/またはPartition [Max | Min] Nodesフラグが設定されている場合、このパーティションレベルの境界は無視できます。その場合、ジョブは、QOSに関連付けられた制限、および/または上記の順序に関連するアソシエーションレベルに適用されます。

Configuration

Scheduling policy information must be stored in a database as specified by the AccountingStorageType configuration parameter in the slurm.conf configuration file. Information can be recorded in a MySQL or MariaDB database. For security and performance reasons, the use of SlurmDBD (Slurm Database Daemon) as a front-end to the database is strongly recommended. SlurmDBD uses a Slurm authentication plugin (e.g. MUNGE). SlurmDBD also uses an existing Slurm accounting storage plugin to maximize code reuse. SlurmDBD uses data caching and prioritization of pending requests in order to optimize performance. While SlurmDBD relies upon existing Slurm plugins for authentication and database use, the other Slurm commands and daemons are not required on the host where SlurmDBD is installed. Only the slurmdbd and slurm-plugins RPMs are required for SlurmDBD execution.
スケジュールポリシー情報は、slurm.conf構成ファイルのAccountingStorageType構成パラメーターで指定されているように、データベースに格納する必要があります。情報は、MySQLまたはMariaDBデータベースに記録できます。セキュリティとパフォーマンスの理由から、データベースのフロントエンドとしてSlurmDBD（Slurm Database Daemon）を使用することを強くお勧めします。SlurmDBDはSlurm認証プラグイン（例：MUNGE）を使用します。SlurmDBDは、既存のSlurmアカウンティングストレージプラグインを使用して、コードの再利用を最大化します。SlurmDBDは、パフォーマンスを最適化するために、データキャッシュと保留中の要求の優先順位付けを使用します。SlurmDBDは認証とデータベースの使用を既存のSlurmプラグインに依存していますが、SlurmDBDがインストールされているホストでは、他のSlurmコマンドとデーモンは必要ありません。

Both accounting and scheduling policies are configured based upon an association. An association is a 4-tuple consisting of the cluster name, bank account, user and (optionally) the Slurm partition. In order to enforce scheduling policy, set the value of AccountingStorageEnforce. This option contains a comma separated list of options you may want to enforce. The valid options are:
アカウンティングとスケジューリングの両方のポリシーは、関連付けに基づいて構成されます。関連付けは、クラスター名、銀行口座、ユーザー、および（オプションで）Slurmパーティションで構成される4タプルです。スケジューリングポリシーを適用するには、AccountingStorageEnforceの値を設定します。このオプションには、強制したいオプションのコンマ区切りのリストが含まれています。有効なオプションは次のとおりです。

• associations - This will prevent users from running jobs if their association is not in the database. This option will prevent users from accessing invalid accounts.
  関連付け-これにより、ユーザーの関連付けがデータベースにない場合、ユーザーはジョブを実行できなくなります。このオプションは、ユーザーが無効なアカウントにアクセスするのを防ぎます。
  
• limits - This will enforce limits set to associations. By setting this option, the 'associations' option is also set.
  制限-これにより、関連付けに設定された制限が適用されます。このオプションを設定すると、「関連付け」オプションも設定されます。
  
• qos - This will require all jobs to specify (either overtly or by default) a valid qos (Quality of Service). QOS values are defined for each association in the database. By setting this option, the 'associations' option is also set.
  qos-すべてのジョブで有効なqos（サービス品質）を（明示的またはデフォルトで）指定する必要があります。QOS値は、データベース内の関連付けごとに定義されます。このオプションを設定すると、「関連付け」オプションも設定されます。
  
• safe - This will ensure a job will only be launched when using an association or qos that has a GrpTRESMins limit set if the job will be able to run to completion. Without this option set, jobs will be launched as long as their usage hasn't reached the cpu-minutes limit which can lead to jobs being launched but then killed when the limit is reached. By setting this option, both the 'associations' option and the 'limits' option are set automatically.
  安全-これにより、GrpTRESMins制限が設定されている関連付けまたはQoSを使用している場合にのみ、ジョブを実行してジョブを完了できるようになります。このオプションが設定されていない場合、使用量がcpu-分の制限に達していない限りジョブが起動され、ジョブが起動される可能性がありますが、制限に達すると強制終了されます。このオプションを設定すると、「関連付け」オプションと「制限」オプションの両方が自動的に設定されます。
  
• wckeys - This will prevent users from running jobs under a wckey that they don't have access to. By using this option, the 'associations' option is also set. The 'TrackWCKey' option is also set to true.
  wckeys-これにより、ユーザーはアクセス権のないwckeyでジョブを実行できなくなります。このオプションを使用すると、「関連付け」オプションも設定されます。'TrackWCKey'オプションもtrueに設定されています。
  

NOTE: The association is a combination of cluster, account, user names and optional partition name.
注記：関連付けは、クラスター、アカウント、ユーザー名、およびオプションのパーティション名の組み合わせです。

Without AccountingStorageEnforce being set (the default behavior) jobs will be executed based upon policies configured in Slurm on each cluster.
AccountingStorageEnforceが設定されていない場合（デフォルトの動作）、各クラスターのSlurmで構成されたポリシーに基づいてジョブが実行されます。

Tools

The tool used to manage accounting policy is sacctmgr. It can be used to create and delete cluster, user, bank account, and partition records plus their combined association record. See man sacctmgr for details on this tools and examples of its use.
アカウンティングポリシーの管理に使用されるツールはsacctmgrです。これを使用して、クラスター、ユーザー、銀行口座、パーティションのレコードに加えて、それらを組み合わせた関連レコードを作成および削除できます。このツールの詳細とその使用例については、man sacctmgrを参照してください。

Changes made to the scheduling policy are uploaded to the Slurm control daemons on the various clusters and take effect immediately. When an association is deleted, all running or pending jobs which belong to that association are immediately canceled. When limits are lowered, running jobs will not be canceled to satisfy the new limits, but the new lower limits will be enforced.
スケジューリングポリシーに加えられた変更は、さまざまなクラスターのSlurm制御デーモンにアップロードされ、すぐに有効になります。アソシエーションが削除されると、そのアソシエーションに属する実行中または保留中のすべてのジョブがすぐにキャンセルされます。制限を下げると、実行中のジョブはキャンセルされずに新しい制限が満たされますが、新しい低い制限が適用されます。

Limits in both Associations and QOS

When dealing with Associations, most of these limits are available not only for a user association, but also for each cluster and account. If a new association is created for some user and a scheduling policy option is not specified the default will be: the option for the cluster/account pair, and if both are not specified then the option for the cluster, and if that also is not specified then no limit will apply.
アソシエーションを処理する場合、これらの制限のほとんどは、ユーザーアソシエーションだけでなく、各クラスターおよびアカウントにも使用できます。一部のユーザーに対して新しい関連付けが作成され、スケジューリングポリシーオプションが指定されていない場合、デフォルトは次のようになります。クラスター/アカウントペアのオプション、両方が指定されていない場合はクラスターのオプション、それも指定されていない場合指定した場合、制限は適用されません。

NOTE: Unless noted, if a job request breaches a given limit the job will pend unless the job's QOS has the DenyOnLimit flag set, which will cause the job to be denied at submission. When Grp limits are considered with respect to this flag the Grp limit is treated as a Max limit.
注：特に明記しない限り、ジョブリクエストが所定の制限に違反すると、ジョブのQOSにDenyOnLimitフラグが設定されていない限り、ジョブは保留されます。これにより、ジョブは送信時に拒否されます。このフラグに関してGrp制限が考慮される場合、Grp制限は最大制限として扱われます。

NOTE: When modifying a TRES field with sacctmgr, one must specify which TRES to modify (see TRES for complete list) as in the following examples:
注：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
  

• GrpTRESMins= The total number of TRES minutes that can possibly be used by past, present and future jobs running from an association and its children or QOS. If this limit is reached all jobs running in this group will be killed, and no new jobs will be allowed to run. This usage is decayed (at a rate of PriorityDecayHalfLife). It can also be reset (according to PriorityUsageResetPeriod) in order to allow jobs to run against the association tree or QOS again. QOS that have the NoDecay flag set do not decay GrpTRESMins, see QOS Options for details. This limit only applies when using the Priority Multifactor plugin.
  GrpTRESMins =アソシエーションとその子またはQOSから実行されている過去、現在、未来のジョブが使用できるTRES分数の合計。この制限に達すると、このグループで実行中のすべてのジョブが強制終了され、新しいジョブの実行が許可されなくなります。この使用量は減少します（PriorityDecayHalfLifeの割合で）。また、（PriorityUsageResetPeriodに従って）リセットして、ジョブを関連ツリーまたはQOSに対して再度実行できるようにすることもできます。NoDecayフラグが設定されているQOSは、GrpTRESMinsを減衰させません。詳細については、QOSオプションを参照してください。この制限は、Priority Multifactorプラグインを使用する場合にのみ適用されます。
  
• GrpTRESRunMins= Used to limit the combined total number of TRES minutes used by all jobs running with an association and its children or QOS. This takes into consideration time limit of running jobs and consumes it, if the limit is reached no new jobs are started until other jobs finish to allow time to free up.
  GrpTRESRunMins =アソシエーションとその子またはQOSで実行されているすべてのジョブによって使用されるTRES分を組み合わせた合計数を制限するために使用されます。これは、実行中のジョブの時間制限を考慮してそれを消費します。制限に達した場合、他のジョブが終了して時間を解放するまで、新しいジョブは開始されません。
  
v
• GrpTRES= The total count of TRES able to be used at any given time from jobs running from an association and its children or QOS. If this limit is reached new jobs will be queued but only allowed to run after resources have been relinquished from this group.
• GrpJobs= The total number of jobs able to run at any given time from an association and its children QOS. If this limit is reached new jobs will be queued but only allowed to run after previous jobs complete from this group.
  GrpJobs =関連付けとその子QOSから任意の時点で実行できるジョブの総数。この制限に達すると、新しいジョブがキューに入れられますが、このグループからの前のジョブが完了した後にのみ実行が許可されます。
  
• GrpJobsAccrue= The total number of pending jobs able to accrue age priority at any given time from an association and its children QOS. If this limit is reached new jobs will be queued but not accrue age priority until after previous jobs are removed from pending in this group. This limit does not determine if the job can run or not, it only limits the age factor of the priority.
  GrpJobsAccrue =関連付けとその子のQOSから、いつでも年齢の優先順位を獲得できる保留中のジョブの総数。この制限に達すると、新しいジョブはキューに入れられますが、前のジョブがこのグループの保留状態から削除されるまで、経過時間の優先順位は発生しません。この制限は、ジョブを実行できるかどうかを決定するのではなく、優先度の経過時間係数を制限するだけです。
  
• GrpSubmitJobs= The total number of jobs able to be submitted to the system at any given time from an association and its children or QOS. If this limit is reached new submission requests will be denied until previous jobs complete from this group.
  GrpSubmitJobs =アソシエーションとその子またはQOSから任意の時点でシステムに送信できるジョブの総数。この制限に達すると、このグループからの前のジョブが完了するまで、新しい送信要求は拒否されます。
  
• GrpWall= The maximum wall clock time any job submitted to this group can run for. If this limit is reached submission requests will be denied. This usage is decayed (at a rate of PriorityDecayHalfLife). It can also be reset (according to PriorityUsageResetPeriod) in order to allow jobs to run against the association tree or QOS again. QOS that have the NoDecay flag set do not decay GrpWall. See QOS Options for details.
  GrpWall =このグループに送信されたジョブを実行できる最大の実時間。この制限に達した場合、送信リクエストは拒否されます。この使用量は減少します（PriorityDecayHalfLifeの割合で）。また、（PriorityUsageResetPeriodに従って）リセットして、ジョブを関連ツリーまたはQOSに対して再度実行できるようにすることもできます。NoDecayフラグが設定されているQOSは、GrpWallを減衰させません。詳細については、QOSオプションを参照してください。
  
• MaxTRESMinsPerJob= A limit of TRES minutes to be used by a job. If this limit is reached the job will be killed if not running in Safe mode, otherwise the job will pend until enough time is given to complete the job.
  MaxTRESMinsPerJob =ジョブが使用するTRES分の制限。この制限に達した場合、セーフモードで実行されていなければジョブは強制終了されます。そうでない場合、ジョブはジョブを完了するのに十分な時間が与えられるまで保留されます。
  
• MaxTRESPerJob= The maximum size in TRES any given job can have from the association/QOS.
  MaxTRESPerJob =特定のジョブが関連付け/ QOSから取得できるTRESの最大サイズ。
  
• MaxTRESPerNode= The maximum size in TRES each node in a job allocation can use.
  MaxTRESPerNode =ジョブ割り当ての各ノードが使用できるTRESの最大サイズ。
  
• MaxWallDurationPerJob= The maximum wall clock time any individual job can run for in the given association/QOS. If this limit is reached the job will be denied at submission.
  MaxWallDurationPerJob =特定のアソシエーション/ QOSで個々のジョブを実行できる最大の実時間。この制限に達すると、ジョブは送信時に拒否されます。
  
• MinPrioThreshold= Used to override bf_min_prio_reserve. See bf_min_prio_reserve for details.
  MinPrioThreshold = bf_min_prio_reserveをオーバーライドするために使用されます。詳細については、bf_min_prio_reserveを参照してください。
  

Association specific scheduling policies supported

サポートされている関連付け固有のスケジューリングポリシー

These represent the scheduling policies unique to associations. Shared policies and limits a QOS has in common are listed above.
これらは、関連付けに固有のスケジューリングポリシーを表します。QOSに共通する共有ポリシーと制限は上記にリストされています。

• Fairshare= Integer value used for determining priority. Essentially this is the amount of claim this association and its children have to the above system. Can also be the string "parent", when used on a user this means that the parent association is used for fairshare. If Fairshare=parent is set on an account, that account's children will be effectively re-parented for fairshare calculations to the first parent of their parent that is not Fairshare=parent. Limits remain the same, only its fairshare value is affected.
  Fairshare =優先度の決定に使用される整数値。基本的に、これはこの協会とその子供たちが上記のシステムに対して持っている主張の量です。文字列「parent」も使用できます。これは、ユーザーで使用される場合、親の関連付けがフェアシェアに使用されることを意味します。アカウントにFairshare = parentが設定されている場合、そのアカウントの子は、Fairshare = parentでない親の最初の親に対して、フェアシェアの計算のために効果的に再親化されます。制限は同じままで、フェアシェア値のみが影響を受けます。
  
• MaxJobs= The total number of jobs able to run at any given time for the given association. If this limit is reached, new jobs will be queued but only allowed to run after existing jobs in the association complete.
  MaxJobs =特定の関連付けで特定の時間に実行できるジョブの総数。この制限に達すると、新しいジョブはキューに入れられますが、関連付けの既存のジョブが完了した後にのみ実行が許可されます。
  
• MaxJobsAccrue= The maximum number of pending jobs able to accrue age priority at any given time for the given association. If this limit is reached, new jobs will be queued but will not accrue age priority until after existing jobs in the association are moved from a pending state. This limit does not determine if the job can run, it only limits the age factor of the priority.
  MaxJobsAccrue =特定のアソシエーションの任意の時点で年齢優先度を獲得できる保留中のジョブの最大数。この制限に達すると、新しいジョブはキューに入れられますが、関連付け内の既存のジョブが保留状態から移動されるまで、年齢の優先順位は蓄積されません。この制限は、ジョブを実行できるかどうかを決定するのではなく、優先度の経過時間係数を制限するだけです。
  
• MaxSubmitJobs= The maximum number of jobs able to be submitted to the system at any given time from the given association. If this limit is reached, new submission requests will be denied until existing jobs in this association complete.
  MaxSubmitJobs =特定の関連付けから特定の時間にシステムに送信できるジョブの最大数。この制限に達すると、この関連付けの既存のジョブが完了するまで、新しい送信要求は拒否されます。
  
• QOS= comma separated list of QOS's an association is able to run.
  QOS =関連付けを実行できるQOSのカンマ区切りリスト。
  

QOS specific limits supported

サポートされるQOS固有の制限

• MaxJobsAccruePerAccount= The maximum number of pending jobs an account (or subacct) can have accruing age priority at any given time. This limit does not determine if the job can run, it only limits the age factor of the priority.
  MaxJobsAccruePerAccount =アカウント（またはサブアカウント）がいつでも経過年齢優先度を獲得できる保留中のジョブの最大数。この制限は、ジョブを実行できるかどうかを決定するのではなく、優先度の経過時間係数を制限するだけです。
  
• MaxJobsAccruePerUser= The maximum number of pending jobs a user can have accruing age priority at any given time. This limit does not determine if the job can run, it only limits the age factor of the priority.
  MaxJobsAccruePerUser =ユーザーが任意の時点で経過優先度を獲得できる保留中のジョブの最大数。この制限は、ジョブを実行できるかどうかを決定するのではなく、優先度の経過時間係数を制限するだけです。
  
• MaxJobsPerAccount= The maximum number of jobs an account (or subaccount) can have running at a given time.
  MaxJobsPerAccount =アカウント（またはサブアカウント）が同時に実行できるジョブの最大数。
  
• MaxJobsPerUser= The maximum number of jobs a user can have running at a given time.
  MaxJobsPerUser =特定の時間にユーザーが実行できるジョブの最大数。
  
• MaxSubmitJobsPerAccount= The maximum number of jobs an account (or subaccount) can have running and pending at a given time.
  MaxSubmitJobsPerAccount =アカウント（またはサブアカウント）が同時に実行および保留できるジョブの最大数。
  
• MaxSubmitJobsPerUser= The maximum number of jobs a user can have running and pending at a given time.
  MaxSubmitJobsPerUser =特定の時間にユーザーが実行および保留できるジョブの最大数。
  
• MaxTRESPerAccount= The maximum number of TRES an account can allocate at a given time.
  MaxTRESPerAccount =アカウントが特定の時間に割り当てることができるTRESの最大数。
  
• MaxTRESPerUser= The maximum number of TRES a user can allocate at a given time.
  MaxTRESPerUser =ユーザーが特定の時間に割り当てることができるTRESの最大数。
  
• MinTRESPerJob= The minimum size in TRES any given job can have when using the requested QOS.
  MinTRESPerJob =要求されたQOSを使用するときに、特定のジョブが持つことができるTRESの最小サイズ。
  

The MaxNodes and MaxWall options already exist in Slurm's configuration on a per-partition basis, but the above options provide the ability to impose limits on a per-user basis. The MaxJobs option provides an entirely new mechanism for Slurm to control the workload any individual may place on a cluster in order to achieve some balance between users.
MaxNodesおよびMaxWallオプションは、パーティションごとにSlurmの構成にすでに存在しますが、上記のオプションは、ユーザーごとに制限を課す機能を提供します。MaxJobsオプションは、Slurmがまったく新しいメカニズムを提供し、ユーザー間のバランスをとるために、個人がクラスターにかけるワークロードを制御します。

Fair-share scheduling is based upon the hierarchical bank account data maintained in the Slurm database. More information can be found in the priority/multifactor plugin description.
フェアシェアのスケジューリングは、Slurmデータベースに保持されている階層的な銀行口座データに基づいています。詳細については、priority / multifactorプラグインの説明を参照してください。

Specific limits over GRES

When a GRES has a type associated with it and a limit is applied over this specific type (e.g. MaxTRESPerUser=gres/gpu:tesla=1) if a user requests a generic gres, the type's limit will not be enforced. In this situation an additional lua job submit plugin to check the user request may become useful. For example, if one requests --gres=gpu:2 having a limit set of MaxTRESPerUser=gres/gpu:tesla=1, the limit won't be enforced so it will still be possible to get two teslas.
GRESに関連付けられたタイプがあり、ユーザーが一般的なgresを要求した場合、この特定のタイプ（たとえば、MaxTRESPerUser = gres / gpu：tesla = 1）に制限が適用される場合、タイプの制限は適用されません。この状況では、ユーザー要求をチェックするための追加のluaジョブ送信プラグインが役立つ場合があります。たとえば、MaxTRESPerUser = gres / gpu：tesla = 1の制限セットを持つ--gres = gpu：2をリクエストした場合、制限は適用されないため、2つのテスラを取得することは可能です。

This is due to a design limitation. The only way to enforce such a limit is to combine the specification of the limit with a job submit plugin that forces the user to always request a specific type model.
これは設計上の制限によるものです。このような制限を強制する唯一の方法は、制限の仕様を、ユーザーが常に特定のタイプモデルを要求するように強制するジョブ送信プラグインと組み合わせることです。

An example of basic lua job submit plugin function could be:
基本的なluaジョブ送信プラグイン関数の例は次のとおりです。

function slurm_job_submit(job_desc, part_list, submit_uid)
   if (job_desc.gres ~= nil)
   then
      for g in job_desc.gres:gmatch("[^,]+")
      do
	 bad = string.match(g,'^gpu[:]*[0-9]*$')
	 if (bad ~= nil)
	 then
	    slurm.log_info("User specified gpu GRES without type: %s", bad)
	    slurm.user_msg("You must always specify a type when requesting gpu GRES")
	    return slurm.ERROR
	 end
      end
   end
end

Having this script and the limit in place will force the users to always specify a gpu with its type, thus enforcing the limits for each specific model.
このスクリプトと制限を設定すると、ユーザーは常にそのタイプでgpuを指定しなければならず、特定のモデルごとに制限が適用されます。

It is also advisable to set AccountingStorageTRES for both generic and specific gres types, otherwise requests that ask for generic only gpus won't be accounted for. Set this for example to:
総称と特定の両方のgresタイプにAccountingStorageTRESを設定することもお勧めします。そうしないと、総称のみのgpusを要求するリクエストは考慮されません。たとえば、これを次のように設定します。

AccountingStorageTRES=gres/gpu,gres/gpu:tesla

See Trackable Resources TRES for details.

Last modified 8 April 2020