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とパーティションQOSの順序は、QOSフラグ「OverPartQOS」を使用して元に戻すことができます。

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.
注：次の制限を除いて、上記で指定された優先順位が尊重されます：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.
これらの制限については、ジョブがQOSやアソシエーションの制限で実施されている場合でも、下部にリストされていても、パーティションレベルで課されている制限を超えることはできません。
So the default for these 3 types of limits is that they are upper bound by the Partition one.
したがって、これら3種類の制限のデフォルトは、パーティション1の上限です。
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.
それぞれのQOSPartitionTimeLimitおよび/または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.
スケジューリングポリシー情報は、slurm.conf構成ファイルのAccountingStorageType構成パラメーターで指定されているようにデータベースに保存する必要があります。
Information can be recorded in a MySQL or MariaDB database.
情報は、MySQLまたはMariaDBデータベースに記録できます。
For security and performance reasons, the use of SlurmDBD (Slurm Database Daemon) as a front-end to the database is strongly recommended.
セキュリティとパフォーマンスの理由から、データベースのフロントエンドとしてSlurmDBD（Slurm Database Daemon）を使用することを強くお勧めします。
SlurmDBD uses a Slurm authentication plugin (e.g. MUNGE).
SlurmDBDは、Slurm認証プラグイン（MUNGEなど）を使用します。
SlurmDBD also uses an existing Slurm accounting storage plugin to maximize code reuse.
SlurmDBDは、既存のSlurmアカウンティングストレージプラグインも使用して、コードの再利用を最大化します。
SlurmDBD uses data caching and prioritization of pending requests in order to optimize performance.
SlurmDBDは、パフォーマンスを最適化するために、データキャッシュと保留中のリクエストの優先順位付けを使用します。
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.
SlurmDBDは、認証とデータベースの使用を既存のSlurmプラグインに依存していますが、SlurmDBDがインストールされているホストでは、他のSlurmコマンドとデーモンは必要ありません。
Only the slurmdbd and slurm-plugins RPMs are required for SlurmDBD execution.
SlurmDBDの実行には、slurmdbdおよびslurm-pluginsRPMのみが必要です。

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.
アソシエーションは、クラスター名、銀行口座、ユーザー、および（オプションで）Slurmパーティションで構成される4タプルです。
In order to enforce scheduling policy, set the value of AccountingStorageEnforce.
スケジューリングポリシーを適用するには、AccountingStorageEnforceの値を設定します。
This option contains a comma separated list of options you may want to enforce.
このオプションには、強制する可能性のあるオプションのコンマ区切りリストが含まれています。
The valid options are:
有効なオプションは次のとおりです。

• 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-これにより、すべてのジョブで有効なqos（サービス品質）を（明示的またはデフォルトで）指定する必要があります。
  QOS values are defined for each association in the database.
  QOS値は、データベース内の関連付けごとに定義されます。
  By setting this option, the 'associations' option is also set.
  このオプションを設定すると、「関連付け」オプションも設定されます。
  
• 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.
  安全-これにより、ジョブを完了まで実行できる場合に、GrpTRESMins制限が設定されているアソシエーションまたはQoSを使用している場合にのみジョブが起動されるようになります。
  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.
  このオプションが設定されていない場合、ジョブは、使用量がCPU分制限に達していない限り起動されます。これにより、ジョブが起動されますが、制限に達すると強制終了されます。
  By setting this option, both the 'associations' option and the 'limits' option are set automatically.
  このオプションを設定すると、「関連付け」オプションと「制限」オプションの両方が自動的に設定されます。
  
• wckeys - This will prevent users from running jobs under a wckey that they don't have access to.
  wckeys-これにより、ユーザーはアクセスできないwckeyでジョブを実行できなくなります。
  By using this option, the 'associations' option is also set.
  このオプションを使用すると、「関連付け」オプションも設定されます。
  The 'TrackWCKey' option is also set to true.
  '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.
アカウンティングポリシーの管理に使用されるツールは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.
このツールの詳細とその使用例については、mansacctmgrを参照してください。

Changes made to the scheduling policy are uploaded to the Slurm control daemons on the various clusters and take effect immediately.
スケジューリングポリシーに加えられた変更は、さまざまなクラスターのSlurm制御デーモンにアップロードされ、すぐに有効になります。
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.
制限が引き下げられた場合、実行中のジョブは新しい制限を満たすためにキャンセルされませんが、新しい下限が適用されます。

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.
注：特に明記されていない限り、ジョブリクエストが特定の制限に違反した場合、ジョブのQOSにDenyOnLimitフラグが設定されていない限り、ジョブは保留されます。これにより、送信時にジョブが拒否されます。
When Grp limits are considered with respect to this flag the Grp limit is treated as a Max limit.
このフラグに関して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.
  GrpTRESMins =アソシエーションとその子またはQOSから実行されている過去、現在、および将来のジョブで使用できる可能性のあるTRES分の合計数。
  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).
  この使用法は減衰します（PriorityDecayHalfLifeの割合で）。
  It can also be reset (according to PriorityUsageResetPeriod) in order to allow jobs to run against the association tree or QOS again.
  また、アソシエーションツリーまたはQOSに対してジョブを再度実行できるようにするために、（PriorityUsageResetPeriodに従って）リセットすることもできます。
  QOS that have the NoDecay flag set do not decay GrpTRESMins, see QOS Options for details.
  NoDecayフラグが設定されているQOSは、GrpTRESMinsを減衰させません。詳細については、QOSオプションを参照してください。
  This limit only applies when using the Priority Multifactor plugin.
  この制限は、PriorityMultifactorプラグインを使用する場合にのみ適用されます。
  
• GrpTRESRunMins= Used to limit the combined total number of TRES minutes used by all jobs running with an association and its children or QOS.
  GrpTRESRunMins =アソシエーションとその子またはQOSで実行されているすべてのジョブによって使用されるTRES分の合計数を制限するために使用されます。
  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.
  これは、実行中のジョブの時間制限を考慮してそれを消費します。制限に達した場合、他のジョブが終了して時間を解放するまで、新しいジョブは開始されません。
  
• 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.
  GrpTRES =アソシエーションとその子またはQOSから実行されているジョブからいつでも使用できるTRESの総数。
  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.
  GrpJobs =アソシエーションとその子QOSから任意の時点で実行できるジョブの総数。
  If this limit is reached new jobs will be queued but only allowed to run after previous jobs complete from this group.
  この制限に達すると、新しいジョブはキューに入れられますが、このグループからの前のジョブが完了した後にのみ実行が許可されます。
  
• GrpJobsAccrue= The total number of pending jobs able to accrue age priority at any given time from an association and its children QOS.
  GrpJobsAccrue =アソシエーションとその子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.
  この制限は、ジョブを実行できるかどうかを決定するものではなく、優先度の経過時間係数を制限するだけです。
  
• 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.
  GrpSubmitJobs =アソシエーションとその子またはQOSから任意の時点でシステムに送信できるジョブの総数。
  If this limit is reached new submission requests will be denied until previous jobs complete from this group.
  この制限に達すると、このグループからの前のジョブが完了するまで、新しい送信要求は拒否されます。
  
• GrpWall= The maximum wall clock time any job submitted to this group can run for.
  GrpWall =このグループに送信されたジョブを実行できる最大実時間。
  If this limit is reached submission requests will be denied.
  この制限に達すると、送信リクエストは拒否されます。
  This usage is decayed (at a rate of PriorityDecayHalfLife).
  この使用法は減衰します（PriorityDecayHalfLifeの割合で）。
  It can also be reset (according to PriorityUsageResetPeriod) in order to allow jobs to run against the association tree or QOS again.
  また、アソシエーションツリーまたはQOSに対してジョブを再度実行できるようにするために、（PriorityUsageResetPeriodに従って）リセットすることもできます。
  QOS that have the NoDecay flag set do not decay GrpWall.
  NoDecayフラグが設定されているQOSは、GrpWallを減衰させません。
  See QOS Options for details.
  詳細については、QOSオプションを参照してください。
  
• MaxTRESMinsPerJob= A limit of TRES minutes to be used by a job.
  MaxTRESMinsPerJob =ジョブで使用されるTRES分の制限。
  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.
  この制限に達した場合、セーフモードで実行されていない場合、ジョブは強制終了されます。それ以外の場合、ジョブは、ジョブを完了するのに十分な時間が与えられるまで保留されます。
  
• 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.
  MaxWallDurationPerJob =指定されたアソシエーション/ QOSで個々のジョブを実行できる最大実時間。
  If this limit is reached the job will be denied at submission.
  この制限に達した場合、ジョブは送信時に拒否されます。
  
• MinPrioThreshold= Used to override bf_min_prio_reserve.
  MinPrioThreshold = bf_min_prio_reserveをオーバーライドするために使用されます。
  See bf_min_prio_reserve for details.
  詳細については、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.
  Fairshare =優先度の決定に使用される整数値。
  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.
  文字列「parent」にすることもできます。これは、ユーザーで使用する場合、親の関連付けがフェアシェアに使用されることを意味します。
  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.
  Fairshare = parentがアカウントに設定されている場合、そのアカウントの子は、Fairshare = parentではない親の最初の親に対して、フェアシェア計算のために効果的に再ペアレント化されます。
  Limits remain the same, only its fairshare value is affected.
  制限は同じままで、フェアシェア値のみが影響を受けます。
  
• MaxJobs= The total number of jobs able to run at any given time for the given association.
  MaxJobs =指定された関連付けに対して任意の時点で実行できるジョブの総数。
  If this limit is reached, new jobs will be queued but only allowed to run after existing jobs in the association complete.
  この制限に達すると、新しいジョブはキューに入れられますが、関連付け内の既存のジョブが完了した後にのみ実行が許可されます。
  
• MaxJobsAccrue= The maximum number of pending jobs able to accrue age priority at any given time for the given association.
  MaxJobsAccrue =指定されたアソシエーションの任意の時点で年齢優先度を獲得できる保留中のジョブの最大数。
  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.
  この制限は、ジョブを実行できるかどうかを決定するものではなく、優先度の経過時間係数を制限するだけです。
  
• MaxSubmitJobs= The maximum number of jobs able to be submitted to the system at any given time from the given association.
  MaxSubmitJobs =指定されたアソシエーションから任意の時点でシステムに送信できるジョブの最大数。
  If this limit is reached, new submission requests will be denied until existing jobs in this association complete.
  この制限に達すると、この関連付けの既存のジョブが完了するまで、新しい送信要求は拒否されます。
  
• 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.
  MaxJobsAccruePerAccount =アカウント（またはサブアカウント）が任意の時点で発生年齢の優先順位を持つことができる保留中のジョブの最大数。
  This limit does not determine if the job can run, it only limits the age factor of the priority.
  この制限は、ジョブを実行できるかどうかを決定するものではなく、優先度の経過時間係数を制限するだけです。
  
• MaxJobsAccruePerUser= The maximum number of pending jobs a user can have accruing age priority at any given time.
  MaxJobsAccruePerUser =ユーザーが任意の時点で発生年齢の優先順位を持つことができる保留中のジョブの最大数。
  This limit does not determine if the job can run, it only limits the age factor of the priority.
  この制限は、ジョブを実行できるかどうかを決定するものではなく、優先度の経過時間係数を制限するだけです。
  
• 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.
MaxNodesおよびMaxWallオプションは、パーティションごとにSlurmの構成にすでに存在しますが、上記のオプションは、ユーザーごとに制限を課す機能を提供します。
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.
MaxJobsオプションは、ユーザー間のバランスを実現するために、個人がクラスターに配置する可能性のあるワークロードを制御するためのまったく新しいメカニズムをSlurmに提供します。

Fair-share scheduling is based upon the hierarchical bank account data maintained in the Slurm database.
フェアシェアスケジューリングは、Slurmデータベースに保持されている階層的な銀行口座データに基づいています。
More information can be found in the priority/multifactor plugin description.
詳細については、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.
GRESにタイプが関連付けられていて、この特定のタイプに制限が適用されている場合（MaxTRESPerUser = gres / gpu：tesla = 1など）、ユーザーが汎用gresを要求すると、タイプの制限は適用されません。
In this situation an additional lua job submit plugin to check the user request may become useful.
この状況では、ユーザーリクエストをチェックするための追加のluaジョブ送信プラグインが役立つ場合があります。
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.
たとえば、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.
また、ジェネリックと特定のグレスタイプの両方にAccountingStorageTRESを設定することをお勧めします。そうしないと、ジェネリックのみのGPUを要求するリクエストは考慮されません。
Set this for example to:
たとえば、これを次のように設定します。

AccountingStorageTRES=gres/gpu,gres/gpu:tesla

See Trackable Resources TRES for details.

Last modified 8 April 2020