Multifactor Priority Plugin

Contents

Introduction

By default, Slurm assigns job priority on a First In, First Out (FIFO) basis. FIFO scheduling should be configured when Slurm is controlled by an external scheduler.
デフォルトでは、Slurmはジョブの優先順位を先入れ先出し（FIFO）ベースで割り当てます。Slurmが外部スケジューラーによって制御されている場合、FIFOスケジューリングを構成する必要があります。

The PriorityType parameter in the slurm.conf file selects the priority plugin. The default value for this variable is "priority/basic" which enables simple FIFO scheduling. (See Configuration below)
slurm.confファイルのPriorityTypeパラメーターは、優先プラグインを選択します。この変数のデフォルト値は「priority / basic」で、これにより単純なFIFOスケジューリングが可能になります。（以下の構成を参照）

The Multi-factor Job Priority plugin provides a very versatile facility for ordering the queue of jobs waiting to be scheduled.
多要素ジョブ優先度プラグインは、スケジュールされるのを待っているジョブのキューを注文するための非常に用途の広い機能を提供します。

Multi-factor 'Factors'

There are nine factors in the Multi-factor Job Priority plugin that influence job priority:
Multi-factor Job Priorityプラグインには、ジョブの優先度に影響を与える9つの要素があります。

Age
the length of time a job has been waiting in the queue, eligible to be scheduled
ジョブがキューで待機していた時間の長さ、スケジュールに適格
Association
a factor associated with each association
各関連付けに関連付けられている要因
Fair-share
the difference between the portion of the computing resource that has been promised and the amount of resources that has been consumed
約束されたコンピューティングリソースの部分と消費されたリソースの量の違い
Job size
the number of nodes or CPUs a job is allocated
ジョブが割り当てられるノードまたはCPUの数
Nice
a factor that can be controlled by users to prioritize their own jobs.
ユーザーが自分のジョブに優先順位を付けるために制御できる要素。
Partition
a factor associated with each node partition
各ノードパーティションに関連付けられた係数
QOS
a factor associated with each Quality Of Service
各サービス品質に関連する要素
Site
a factor dictated by an administrator or a site-developed job_submit or site_factor plugin
管理者またはサイト開発のjob_submitまたはsite_factorプラグインによって指示された係数
TRES
each TRES Type has its own factor for a job which represents the number of requested/allocated TRES Type in a given partition
各TRESタイプには、特定のパーティション内で要求/割り当てられたTRESタイプの数を表すジョブの独自の係数があります

Additionally, a weight can be assigned to each of the above factors. This provides the ability to enact a policy that blends a combination of any of the above factors in any portion desired. For example, a site could configure fair-share to be the dominant factor (say 70%), set the job size and the age factors to each contribute 15%, and set the partition and QOS influences to zero.
さらに、上記の各要素に重みを割り当てることができます。これにより、上記の要素のいずれかの組み合わせを必要な部分にブレンドするポリシーを制定することができます。たとえば、サイトがフェアシェアを支配的な要因（たとえば70％）に構成し、ジョブサイズと年齢要因をそれぞれ15％寄与するように設定し、パーティションとQOSの影響をゼロに設定できます。

Job Priority Factors In General

The job's priority at any given time will be a weighted sum of all the factors that have been enabled in the slurm.conf file. Job priority can be expressed as:
任意の時点でのジョブの優先順位は、slurm.confファイルで有効にされているすべての要素の加重合計になります。ジョブの優先順位は次のように表すことができます。

Job_priority =
	site_factor +
	(PriorityWeightAge) * (age_factor) +
	(PriorityWeightAssoc) * (assoc_factor) +
	(PriorityWeightFairshare) * (fair-share_factor) +
	(PriorityWeightJobSize) * (job_size_factor) +
	(PriorityWeightPartition) * (partition_factor) +
	(PriorityWeightQOS) * (QOS_factor) +
	SUM(TRES_weight_cpu * TRES_factor_cpu,
	    TRES_weight_<type> * TRES_factor_<type>,
	    ...)
	- nice_factor

All of the factors in this formula are floating point numbers that range from 0.0 to 1.0. The weights are unsigned, 32 bit integers. The job's priority is an integer that ranges between 0 and 4294967295. The larger the number, the higher the job will be positioned in the queue, and the sooner the job will be scheduled. A job's priority, and hence its order in the queue, can vary over time. For example, the longer a job sits in the queue, the higher its priority will grow when the age_weight is non-zero.
この式のすべての要素は、0.0〜1.0の範囲の浮動小数点数です。重みは符号なしの32ビット整数です。ジョブの優先順位は、0から4294967295の範囲の整数です。数値が大きいほど、ジョブはキューの上位に配置され、ジョブはより早くスケジュールされます。ジョブの優先順位、したがってキュー内でのジョブの順序は、時間とともに変化する可能性があります。たとえば、ジョブがキューに長く留まるほど、age_weightがゼロ以外の場合、優先順位が高くなります。

IMPORTANT: The weight values should be high enough to get a good set of significant digits since all the factors are floating point numbers from 0.0 to 1.0. For example, one job could have a fair-share factor of .59534 and another job could have a fair-share factor of .50002. If the fair-share weight is only set to 10, both jobs would have the same fair-share priority. Therefore, set the weights high enough to avoid this scenario, starting around 1000 or so for those factors you want to make predominant.
重要：すべての係数は0.0から1.0までの浮動小数点数であるため、重み値は十分な有効桁のセットを取得するのに十分な高さである必要があります。たとえば、あるジョブのフェアシェア係数が.59534で、別のジョブのフェアシェア係数が.50002の場合があります。フェアシェアの重みが10に設定されているだけの場合、両方のジョブのフェアシェアの優先順位は同じになります。したがって、このシナリオを回避するのに十分な高さの重みを設定します。優先させたい要素については、約1000から始めます。

Age Factor

The age factor represents the length of time a job has been sitting in the queue and eligible to run. In general, the longer a job waits in the queue, the larger its age factor grows. However, the age factor for a dependent job will not change while it waits for the job it depends on to complete. Also, the age factor will not change when scheduling is withheld for a job whose node or time limits exceed the cluster's current limits.
エージ係数は、ジョブがキューに入れられ、実行に適格であった時間の長さを表します。一般に、ジョブがキューで待機する時間が長くなるほど、エージファクターは大きくなります。ただし、依存するジョブのエージファクターは、依存するジョブが完了するまで待機している間は変わりません。また、ノードまたは時間制限がクラスターの現在の制限を超えるジョブのスケジューリングが保留されている場合でも、年齢係数は変更されません。

At some configurable length of time (PriorityMaxAge), the age factor will max out to 1.0.
構成可能な時間の長さ（PriorityMaxAge）で、エージ係数は最大で1.0になります。

Association Factor

Each association can be assigned an integer priority. The larger the number, the greater the job priority will be for jobs that request this association. This priority value is normalized to the highest priority of all the association to become the association factor.
各関連付けには整数の優先順位を割り当てることができます。数値が大きいほど、この関連付けを要求するジョブの優先順位が高くなります。この優先度の値は、すべての関連付けの最高の優先度に正規化され、関連付け係数になります。

Job Size Factor

The job size factor correlates to the number of nodes or CPUs the job has requested. This factor can be configured to favor larger jobs or smaller jobs based on the state of the PriorityFavorSmall boolean in the slurm.conf file. When PriorityFavorSmall is NO, the larger the job, the greater its job size factor will be. A job that requests all the nodes on the machine will get a job size factor of 1.0. When the PriorityFavorSmall Boolean is YES, the single node job will receive the 1.0 job size factor.
ジョブサイズ係数は、ジョブが要求したノードまたはCPUの数に相関します。この係数は、slurm.confファイル内のPriorityFavorSmallブール値の状態に基づいて、大きいジョブまたは小さいジョブを優先するように構成できます。PriorityFavorSmallがNOの場合、ジョブが大きくなるほど、ジョブサイズ係数が大きくなります。マシン上のすべてのノードを要求するジョブは、1.0のジョブサイズ係数を取得します。PriorityFavorSmallブール値がYESの場合、単一ノードジョブは1.0のジョブサイズ係数を受け取ります。

The PriorityFlags value of SMALL_RELATIVE_TO_TIME alters this behavior as follows. The job size in CPUs is divided by the time limit in minutes. The result is divided by the total number of CPUs in the system. Thus a full-system job with a time limit of one will receive a job size factor of 1.0, while a tiny job with a large time limit will receive a job size factor close to 0.0.
SMALL_RELATIVE_TO_TIMEのPriorityFlags値は、この動作を次のように変更します。CPU単位のジョブサイズは、分単位の時間制限で除算されます。結果は、システム内のCPUの総数で除算されます。したがって、時間制限が1のフルシステムジョブは1.0のジョブサイズ係数を受け取り、時間制限が大きい小さなジョブは0.0に近いジョブサイズ係数を受け取ります。

Nice Factor

Users can adjust the priority of their own jobs by setting the nice value on their jobs. Like the system nice, positive values negatively impact a job's priority and positive values increase a job's priority. Only privileged users can specify a negative value. The adjustment range is +/-2147483645.
ユーザーは、ジョブにnice値を設定することにより、自分のジョブの優先度を調整できます。システムのように、正の値はジョブの優先度に悪影響を与え、正の値はジョブの優先度を上げます。特権ユーザーのみが負の値を指定できます。調整範囲は+/- 2147483645です。

Partition Factor

Each node partition can be assigned an integer priority. The larger the number, the greater the job priority will be for jobs that request to run in this partition. This priority value is then normalized to the highest priority of all the partitions to become the partition factor.
各ノードパーティションには、整数の優先順位を割り当てることができます。数値が大きいほど、このパーティションでの実行を要求するジョブのジョブ優先順位が高くなります。この優先度の値は、すべてのパーティションの最高の優先度に正規化されて、パーティションファクターになります。

Quality of Service (QOS) Factor

Each QOS can be assigned an integer priority. The larger the number, the greater the job priority will be for jobs that request this QOS. This priority value is then normalized to the highest priority of all the QOS's to become the QOS factor.
各QOSには整数の優先順位を割り当てることができます。数値が大きいほど、このQOSを要求するジョブのジョブ優先順位が高くなります。この優先度の値は、すべてのQoSの中で最も高い優先度に正規化され、QOS係数になります。

Site Factor

The site factor is a factor that can be set either using scontrol, through a job_submit or site_factor plugin. An example use case, might be a job_submit plugin that sets a specific priority based on how many resources are requested.
サイト係数は、scontrolを使用して、job_submitまたはsite_factorプラグインを介して設定できる係数です。使用例としては、リクエストされたリソースの数に基づいて特定の優先度を設定するjob_submitプラグインがあります。

TRES Factors

Each TRES Type has its own priority factor for a job which represents the amount of TRES Type requested/allocated in a given partition. For global TRES Types, such as Licenses and Burst Buffers, the factor represents the number of TRES Type requested/allocated in the whole system. The more a given TRES Type is requested/allocated on a job, the greater the job priority will be for that job.
各TRESタイプには、特定のパーティションで要求/割り当てられたTRESタイプの量を表す、ジョブに対する独自の優先度係数があります。ライセンスやバーストバッファーなどのグローバルTRESタイプの場合、係数はシステム全体で要求/割り当てられたTRESタイプの数を表します。特定のTRES Typeがジョブに要求/割り当てられるほど、そのジョブのジョブ優先順位は高くなります。

Fair-share Factor

Note: Computing the fair-share factor requires the installation and operation of the Slurm Accounting Database to provide the assigned shares and the consumed, computing resources described below.
注：フェアシェア係数を計算するには、Slurm Accounting Databaseをインストールして操作し、割り当てられたシェアと、以下で説明する消費されたコンピューティングリソースを提供する必要があります。

The fair-share component to a job's priority influences the order in which a user's queued jobs are scheduled to run based on the portion of the computing resources they have been allocated and the resources their jobs have already consumed. The fair-share factor does not involve a fixed allotment, whereby a user's access to a machine is cut off once that allotment is reached.
ジョブの優先度に対するフェアシェアコンポーネントは、割り当てられたコンピューティングリソースの一部とジョブがすでに消費したリソースに基づいて、ユーザーのキューに入れられたジョブの実行がスケジュールされる順序に影響します。フェアシェア要素には固定割り当てが含まれていないため、割り当てに達すると、ユーザーのマシンへのアクセスは遮断されます。

Instead, the fair-share factor serves to prioritize queued jobs such that those jobs charging accounts that are under-serviced are scheduled first, while jobs charging accounts that are over-serviced are scheduled when the machine would otherwise go idle.
代わりに、公平配分係数は、サービスが不足しているアカウント課金アカウントのジョブが最初にスケジュールされるように、キューに入れられたジョブに優先順位を付けるのに役立ちます。

Slurm's fair-share factor is a floating point number between 0.0 and 1.0 that reflects the shares of a computing resource that a user has been allocated and the amount of computing resources the user's jobs have consumed. The higher the value, the higher is the placement in the queue of jobs waiting to be scheduled.
Slurmのフェアシェア係数は0.0から1.0の浮動小数点数で、ユーザーが割り当てられたコンピューティングリソースのシェアと、ユーザーのジョブが消費したコンピューティングリソースの量を反映しています。値が大きいほど、スケジュールされるのを待っているジョブのキューの配置が高くなります。

By default, the computing resource is the computing cycles delivered by a machine in the units of allocated_cpus*seconds. Other resources can be taken into account by configuring a partition's TRESBillingWeights option. The TRESBillingWeights option allows you to account for consumed resources other than just CPUs by assigning different billing weights to different Trackable Resources (TRES) such as CPUs, nodes, memory, licenses and generic resources (GRES). For example, when billing only for CPUs, if a job requests 1CPU and 64GB of memory on a 16CPU, 64GB node the job will only be billed for 1CPU when it really used the whole node.
デフォルトでは、コンピューティングリソースは、allocation_cpus * secondsの単位でマシンが提供するコンピューティングサイクルです。パーティションのTRESBillingWeightsオプションを構成することにより、他のリソースを考慮することができます。TRESBillingWeightsオプションを使用すると、CPU、ノード、メモリ、ライセンス、汎用リソース（GRES）などの異なる追跡可能リソース（TRES）に異なる課金の重みを割り当てることにより、CPU以外の消費されたリソースを考慮することができます。たとえば、CPUのみに課金する場合、ジョブが16CPU、64GBノードで1CPUと64GBのメモリを要求すると、実際にノード全体を使用した場合にのみ、ジョブは1CPUに対して課金されます。

By default, when TRESBillingWeights is configured, a job is billed for each individual TRES used. The billable TRES is calculated as the sum of all TRES types multiplied by their corresponding billing weight.
デフォルトでは、TRESBillingWeightsが構成されている場合、使用される個々のTRESごとにジョブが請求されます。請求可能なTRESは、すべてのTRESタイプの合計に対応する請求の重みを掛けて計算されます。

For example, the following jobs on a partition configured with TRESBillingWeights=CPU=1.0,Mem=0.25G and 16CPU, 64GB nodes would be billed as:
たとえば、TRESBillingWeights = CPU = 1.0、Mem = 0.25Gおよび16CPU、64GBノードで構成されたパーティション上の次のジョブは、次のように請求されます。
 

      CPUs       Mem GB
Job1: (1 *1.0) + (60*0.25) = (1 + 15) = 16
Job2: (16*1.0) + (1 *0.25) = (16+.25) = 16.25
Job3: (16*1.0) + (60*0.25) = (16+ 15) = 31

Another method of calculating the billable TRES is by taking the MAX of the individual TRES' on a node (e.g. cpus, mem, gres) plus the SUM of the global TRES' (e.g. licenses). For example the above job's billable TRES would be calculated as:
請求可能なTRESを計算する別の方法は、ノード（例：cpus、mem、gres）上の個々のTRES 'の最大値に加えて、グローバルTRES'（例：ライセンス）の合計を取ることです。たとえば、上記のジョブの請求可能なTRESは次のように計算されます。
 

          CPUs      Mem GB
Job1: MAX((1 *1.0), (60*0.25)) = 15
Job2: MAX((15*1.0), (1 *0.25)) = 15
Job3: MAX((16*1.0), (64*0.25)) = 16
This method is turned on by defining the MAX_TRES priority flags in the slurm.conf.
このメソッドは、slurm.confでMAX_TRES優先度フラグを定義することでオンになります。

"Fair Tree" Fairshare

As of the 19.05 release, the "Fair Tree" fairshare algorithm has been made the default. Please see the Fair Tree Fairshare documentation for further details.
19.05リリース以降、「フェアツリー」フェアシェアアルゴリズムがデフォルトになりました。詳細については、フェアツリーフェアシェアのドキュメントをご覧ください。

"Classic" Fairshare

As of the 19.05 release, the "classic" fairshare algorithm is no longer the default, and will only be used if PriorityFlags=NO_FAIR_TREE is explicitly configured. Docmentation describing that algorithm has been moved to a separate Classic Fairshare documentation page.
19.05リリース以降、「クラシック」フェアシェアアルゴリズムはデフォルトではなくなり、PriorityFlags = NO_FAIR_TREEが明示的に設定されている場合にのみ使用されます。そのアルゴリズムを説明するドキュメントは、別のClassic Fairshareドキュメントページに移動されました。

The sprio utility

The sprio command provides a summary of the six factors that comprise each job's scheduling priority. While squeue has format options (%p and %Q) that display a job's composite priority, sprio can be used to display a breakdown of the priority components for each job. In addition, the sprio -w option displays the weights (PriorityWeightAge, PriorityWeightFairshare, etc.) for each factor as it is currently configured.
sprioコマンドは、各ジョブのスケジューリング優先順位を構成する6つの要素の要約を提供します。squeueには、ジョブの複合優先順位を表示するフォーマットオプション（％pおよび％Q）がありますが、sprioを使用して、各ジョブの優先順位コンポーネントの詳細を表示できます。さらに、sprio -wオプションは、現在構成されている各要素の重み（PriorityWeightAge、PriorityWeightFairshareなど）を表示します。

Configuration

The following slurm.conf (SLURM_CONFIG_FILE) parameters are used to configure the Multi-factor Job Priority Plugin. See slurm.conf(5) man page for more details.
以下のslurm.conf（SLURM_CONFIG_FILE）パラメーターは、多要素ジョブ優先度プラグインを構成するために使用されます。詳細については、slurm.conf（5）のマニュアルページを参照してください。

PriorityType
Set this value to "priority/multifactor" to enable the Multi-factor Job Priority Plugin. The default value for this variable is "priority/basic" which enables simple FIFO scheduling.
この値を「priority / multifactor」に設定して、Multi-factor Job Priority Pluginを有効にします。この変数のデフォルト値は「priority / basic」で、これにより単純なFIFOスケジューリングが可能になります。
PriorityDecayHalfLife
This determines the contribution of historical usage on the composite usage value. The larger the number, the longer past usage affects fair-share. If set to 0 no decay will be applied. This is helpful if you want to enforce hard time limits per association. If set to 0 PriorityUsageResetPeriod must be set to some interval. The unit is a time string (i.e. min, hr:min:00, days-hr:min:00, or days-hr). The default value is 7-0 (7 days).
これは、複合使用量の値に対する履歴使用量の寄与を決定します。数値が大きいほど、過去の使用時間がフェアシェアに影響します。0に設定すると、減衰は適用されません。これは、関連付けごとに厳しい時間制限を適用する場合に役立ちます。0に設定する場合、PriorityUsageResetPeriodをある間隔に設定する必要があります。単位は時間文字列です（つまり、min、hr：min：00、days-hr：min：00、またはdays-hr）。デフォルト値は7-0（7日）です。
PriorityCalcPeriod
The period of time in minutes in which the half-life decay will be re-calculated. The default value is 5 (minutes).
半減期の減衰が再計算される分単位の期間。デフォルト値は5（分）です。
PriorityUsageResetPeriod
At this interval the usage of associations will be reset to 0. This is used if you want to enforce hard limits of time usage per association. If PriorityDecayHalfLife is set to be 0 no decay will happen and this is the only way to reset the usage accumulated by running jobs. By default this is turned off and it is advised to use the PriorityDecayHalfLife option to avoid not having anything running on your cluster, but if your schema is set up to only allow certain amounts of time on your system this is the way to do it. Applicable only if PriorityType=priority/multifactor. The unit is a time string (i.e. NONE, NOW, DAILY, WEEKLY). The default is NONE.
この間隔で、アソシエーションの使用は0にリセットされます。これは、アソシエーションごとの時間使用のハード制限を強制したい場合に使用されます。PriorityDecayHalfLifeが0に設定されている場合、減衰は発生せず、これが、実行中のジョブによって累積された使用量をリセットする唯一の方法です。デフォルトではこれはオフになっており、クラスターで何も実行されないようにPriorityDecayHalfLifeオプションを使用することをお勧めしますが、システムで一定の時間のみを許可するようにスキーマが設定されている場合は、これがその方法です。PriorityType = priority / multifactorの場合のみ適用されます。単位は時間文字列です（つまり、NONE、NOW、DAILY、WEEKLY）。デフォルトはNONEです。
  • NONE: Never clear historic usage. The default value.
    なし：過去の使用状況を決して消去しません。デフォルト値。
  • NOW: Clear the historic usage now. Executed at startup and reconfiguration time.
    NOW：歴史的な使用法を今クリアします。起動時および再構成時に実行されます。
  • DAILY: Cleared every day at midnight.
    DAILY：毎日深夜0時にクリアされます。
  • WEEKLY: Cleared every week on Sunday at time 00:00.
    毎週：毎週日曜日の00:00にクリアされます。
  • MONTHLY: Cleared on the first day of each month at time 00:00.
    毎月：毎月1日の00:00にクリアされます。
  • QUARTERLY: Cleared on the first day of each quarter at time 00:00.
    四半期：各四半期の最初の日の00:00に決済されます。
  • YEARLY: Cleared on the first day of each year at time 00:00.
    YEARLY：毎年最初の日の00:00に決済されます。
PriorityFavorSmall
A boolean that sets the polarity of the job size factor. The default setting is NO which results in larger node sizes having a larger job size factor. Setting this parameter to YES means that the smaller the job, the greater the job size factor will be.
ジョブサイズ係数の極性を設定するブール。デフォルト設定はNOで、ノードサイズが大きくなり、ジョブサイズ係数が大きくなります。このパラメーターをYESに設定すると、ジョブが小さいほど、ジョブサイズ係数が大きくなります。
PriorityMaxAge
Specifies the queue wait time at which the age factor maxes out. The unit is a time string (i.e. min, hr:min:00, days-hr:min:00, or days-hr). The default value is 7-0 (7 days).
エージ係数が最大になるキュー待機時間を指定します。単位は時間文字列です（つまり、min、hr：min：00、days-hr：min：00、またはdays-hr）。デフォルト値は7-0（7日）です。
PriorityWeightAge
An unsigned integer that scales the contribution of the age factor.
エージファクタの寄与をスケーリングする符号なし整数。
PriorityWeightAssoc
An unsigned integer that scales the contribution of the association factor.
関連係数の寄与をスケーリングする符号なし整数。
PriorityWeightFairshare
An unsigned integer that scales the contribution of the fair-share factor.
フェアシェア係数の寄与をスケーリングする符号なし整数。
PriorityWeightJobSize
An unsigned integer that scales the contribution of the job size factor.
ジョブサイズ係数の寄与をスケーリングする符号なし整数。
PriorityWeightPartition
An unsigned integer that scales the contribution of the partition factor.
分割係数の寄与をスケーリングする符号なし整数。
PriorityWeightQOS
An unsigned integer that scales the contribution of the quality of service factor.
サービス品質係数の寄与をスケーリングする符号なし整数。
PriorityWeightTRES
A list of TRES Types and weights that scales the contribution of each TRES Type's factor.
TRESタイプと各TRESタイプの因子の寄与をスケーリングする重みのリスト。
PriorityFlags
Flags to modify priority behavior. Applicable only if PriorityType=priority/multifactor.
優先順位の動作を変更するためのフラグ。PriorityType = priority / multifactorの場合のみ適用されます。
  • ACCRUE_ALWAYS: If set, priority age factor will be increased despite job dependencies or holds.
    ACCRUE_ALWAYS：設定すると、ジョブの依存関係や保留にかかわらず、優先度の経過係数が増加します。
  • CALCULATE_RUNNING: If set, priorities will be recalculated not only for pending jobs, but also running and suspended jobs.
    CALCULATE_RUNNING：設定すると、保留中のジョブだけでなく、実行中および一時停止中のジョブの優先度も再計算されます。
  • DEPTH_OBLIVIOUS: If set, priority will be calculated based similar to the normal multifactor calculation, but depth of the associations in the tree do not adversely effect their priority. This option automatically enables NO_FAIR_TREE.
    DEPTH_OBLIVIOUS：設定されている場合、優先度は通常の多要素計算と同様に計算されますが、ツリー内の関連付けの深さが優先度に悪影響を与えることはありません。このオプションは、NO_FAIR_TREEを自動的に有効にします。
  • NO_FAIR_TREE: Disables the "fair tree" algorithm, and reverts to "classic" fair share priority scheduling.
    NO_FAIR_TREE：「フェアツリー」アルゴリズムを無効にし、「クラシック」フェアシェア優先スケジューリングに戻します。
  • INCR_ONLY: If set, priority values will only increase in value. Job priority will never decrease in value.
    INCR_ONLY：設定されている場合、優先度の値は増加するだけです。ジョブの優先度の値が下がることはありません。
  • MAX_TRES: If set, the weighted TRES value (e.g. TRESBillingWeights) is calculated as the MAX of individual TRES' on a node (e.g. cpus, mem, gres) plus the sum of all global TRES' (e.g. licenses).
    MAX_TRES：設定されている場合、重み付きTRES値（TRESBillingWeightsなど）は、ノード（例：cpus、mem、gres）上の個々のTRES 'の最大値に、すべてのグローバルTRES'（例：ライセンス）の合計を加えたものとして計算されます。
  • NO_NORMAL_ALL: If set, all NO_NORMAL_* flags are set.
    NO_NORMAL_ALL：設定すると、すべてのNO_NORMAL_ *フラグが設定されます。
  • NO_NORMAL_ASSOC: If set, the associaton factor is not normalized against the highest association priority.
    NO_NORMAL_ASSOC：設定されている場合、関連付け係数は最高の関連付け優先度に対して正規化されません。
  • NO_NORMAL_PART: If set, the partition factor is not normalized against the highest partition PriorityTier
    NO_NORMAL_PART：設定すると、パーティション係数は最高のパーティションPriorityTierに対して正規化されません。
  • NO_NORMAL_QOS: If set, the QOS factor is not normalized against the highest qos priority.
    NO_NORMAL_QOS：設定すると、QOS係数は最高のQoS優先度に対して正規化されません。
  • NO_NORMAL_TRES: If set, the QOS factor is not normalized against the job's partition TRES counts.
    NO_NORMAL_TRES：設定されている場合、QOS係数はジョブのパーティションTRESカウントに対して正規化されません。
  • SMALL_RELATIVE_TO_TIME: If set, the job's size component will be based upon not the job size alone, but the job's size divided by its time limit.
    SMALL_RELATIVE_TO_TIME：設定されている場合、ジョブのサイズコンポーネントは、ジョブサイズのみではなく、ジョブのサイズを制限時間で割った値に基づきます。

Note: As stated above, the six priority factors range from 0.0 to 1.0. As such, the PriorityWeight terms may need to be set to a high enough value (say, 1000) to resolve very tiny differences in priority factors. This is especially true with the fair-share factor, where two jobs may differ in priority by as little as .001. (or even less!)
注：上記のように、6つの優先度係数の範囲は0.0〜1.0です。そのため、PriorityWeightの項は、優先度の要因の非常に小さな違いを解決するために、十分に高い値（たとえば、1000）に設定する必要がある場合があります。これは特に、2つのジョブの優先度が0.001程度異なる場合があるフェアシェアファクターに当てはまります。（またはさらに少ない！）

Configuration Example

The following are sample slurm.conf file settings for the Multi-factor Job Priority Plugin.
以下は、Multi-factor Job Priority Pluginのサンプルslurm.confファイル設定です。

The first example is for running the plugin applying decay over time to reduce usage. Hard limits can be used in this configuration, but will have less effect since usage will decay over time instead of having no decay over time.
最初の例は、減衰を適用してプラグインを実行し、使用量を減らします。この構成ではハード制限を使用できますが、使用量は時間とともに減衰するのではなく、時間とともに減衰するため、効果は低くなります。

# Activate the Multi-factor Job Priority Plugin with decay
PriorityType=priority/multifactor

# 2 week half-life
PriorityDecayHalfLife=14-0

# The larger the job, the greater its job size priority.
PriorityFavorSmall=NO

# The job's age factor reaches 1.0 after waiting in the
# queue for 2 weeks.
PriorityMaxAge=14-0

# This next group determines the weighting of each of the
# components of the Multi-factor Job Priority Plugin.
# The default value for each of the following is 1.
PriorityWeightAge=1000
PriorityWeightFairshare=10000
PriorityWeightJobSize=1000
PriorityWeightPartition=1000
PriorityWeightQOS=0 # don't use the qos factor

This example is for running the plugin with no decay on usage, thus making a reset of usage necessary.
この例は、使用量の減少なしでプラグインを実行するためのものであり、使用量のリセットが必要になります。

# Activate the Multi-factor Job Priority Plugin with decay
PriorityType=priority/multifactor

# apply no decay
PriorityDecayHalfLife=0

# reset usage after 1 month
PriorityUsageResetPeriod=MONTHLY

# The larger the job, the greater its job size priority.
PriorityFavorSmall=NO

# The job's age factor reaches 1.0 after waiting in the
# queue for 2 weeks.
PriorityMaxAge=14-0

# This next group determines the weighting of each of the
# components of the Multi-factor Job Priority Plugin.
# The default value for each of the following is 1.
PriorityWeightAge=1000
PriorityWeightFairshare=10000
PriorityWeightJobSize=1000
PriorityWeightPartition=1000
PriorityWeightQOS=0 # don't use the qos factor

Last modified 1 November 2013