Multifactor Priority Plugin

Contents

Introduction

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

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

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

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.
任意の時点でのジョブの優先順位は、slurm.confファイルで有効になっているすべての要素の加重和になります。
 Job priority can be expressed as:
ジョブの優先度は次のように表すことができます。

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.
この式のすべての要素は、0.0から1.0の範囲の浮動小数点数です。
 The weights are unsigned, 32 bit integers.
重みは符号なし、32ビット整数です。
 The job's priority is an integer that ranges between 0 and 4294967295.
ジョブの優先順位は、0から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.
たとえば、ジョブがキューに長く留まるほど、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.
重要：すべての要素は0.0から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.
たとえば、あるジョブのフェアシェア係数が.59534で、別のジョブのフェアシェア係数が.50002である可能性があります。
 If the fair-share weight is only set to 10, both jobs would have the same fair-share priority.
フェアシェアの重みが10にのみ設定されている場合、両方のジョブのフェアシェアの優先度は同じになります。
 Therefore, set the weights high enough to avoid this scenario, starting around 1000 or so for those factors you want to make predominant.
したがって、このシナリオを回避するのに十分な高さの重みを設定し、支配的にしたい要素については約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.
ジョブサイズ係数は、ジョブが要求したノードまたはCPUの数と相関関係があります。
 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.
この係数は、slurm.confファイルのPriorityFavorSmallブール値の状態に基づいて、より大きなジョブまたはより小さなジョブを優先するように構成できます。
 When PriorityFavorSmall is NO, the larger the job, the greater its job size factor will be.
PriorityFavorSmallがNOの場合、ジョブが大きいほど、ジョブサイズ係数は大きくなります。
 A job that requests all the nodes on the machine will get a job size factor of 1.0.
マシン上のすべてのノードを要求するジョブは、1.0のジョブサイズ係数を取得します。
 When the PriorityFavorSmall Boolean is YES, the single node job will receive the 1.0 job size factor.
PriorityFavorSmallブール値がYESの場合、単一ノードのジョブは1.0ジョブサイズ係数を受け取ります。

The PriorityFlags value of SMALL_RELATIVE_TO_TIME alters this behavior as follows.
SMALL_RELATIVE_TO_TIMEのPriorityFlags値は、この動作を次のように変更します。
 The job size in CPUs is divided by the time limit in minutes.
CPUのジョブサイズは、分単位の制限時間で除算されます。
 The result is divided by the total number of CPUs in the system.
結果は、システム内のCPUの総数で除算されます。
 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.
したがって、制限時間が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.
調整範囲は+/- 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.
各QOSには整数の優先度を割り当てることができます。
 The larger the number, the greater the job priority will be for jobs that request this QOS.
数値が大きいほど、このQOSを要求するジョブのジョブ優先度が高くなります。
 This priority value is then normalized to the highest priority of all the QOS's to become the QOS factor.
次に、この優先度の値は、すべての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.
サイトファクターは、scontrolを使用して、job_submitまたはsite_factorプラグインを介して設定できるファクターです。
 An example use case, might be a job_submit plugin that sets a specific priority based on how many resources are requested.
ユースケースの例としては、要求されたリソースの数に基づいて特定の優先度を設定する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.
各TRESタイプには、特定のパーティションで要求/割り当てられたTRESタイプの量を表すジョブの独自の優先度係数があります。
 For global TRES Types, such as Licenses and Burst Buffers, the factor represents the number of TRES Type requested/allocated in the whole system.
ライセンスやバーストバッファなどのグローバルTRESタイプの場合、係数はシステム全体で要求/割り当てられたTRESタイプの数を表します。
 The more a given TRES Type is requested/allocated on a job, the greater the job priority will be for that job.
特定のTRESタイプがジョブで要求/割り当てられるほど、そのジョブのジョブ優先度は高くなります。

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アカウンティングデータベースをインストールして操作し、割り当てられたシェアと、以下で説明する消費されたコンピューティングリソースを提供する必要があります。

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.
Slurmのフェアシェア係数は、0.0〜1.0の浮動小数点数であり、ユーザーに割り当てられたコンピューティングリソースのシェアと、ユーザーのジョブが消費したコンピューティングリソースの量を反映しています。
 The higher the value, the higher is the placement in the queue of jobs waiting to be scheduled.
値が大きいほど、スケジュールされるのを待っているジョブのキュー内の配置が高くなります。

By default, the computing resource is the computing cycles delivered by a machine in the units of allocated_cpus*seconds.
デフォルトでは、コンピューティングリソースは、assigned_cpus * secondsの単位でマシンによって提供されるコンピューティングサイクルです。
 Other resources can be taken into account by configuring a partition's TRESBillingWeights option.
パーティションのTRESBillingWeightsオプションを構成することにより、他のリソースを考慮に入れることができます。
 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).
TRESBillingWeightsオプションを使用すると、CPU、ノード、メモリ、ライセンス、汎用リソース（GRES）などのさまざまな追跡可能リソース（TRES）にさまざまな請求の重みを割り当てることで、CPUだけでなく消費されたリソースを考慮することができます。
 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.
たとえば、CPUに対してのみ課金する場合、ジョブが16CPU、64GBノードで1CPUと64GBのメモリを要求すると、ジョブは実際にノード全体を使用したときに1CPUに対してのみ課金されます。

By default, when TRESBillingWeights is configured, a job is billed for each individual TRES used.
デフォルトでは、TRESBillingWeightsが構成されている場合、ジョブは使用された個々のTRESごとに請求されます。
 The billable TRES is calculated as the sum of all TRES types multiplied by their corresponding billing weight.
請求可能な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).
請求可能なTRESを計算する別の方法は、ノード（cpus、mem、gresなど）の個々のTRESのMAXと、グローバルTRES（ライセンスなど）の合計を取得することです。
 For example the above job's billable TRES would be calculated as:
たとえば、上記のジョブの請求可能な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.
19.05リリースの時点で、「FairTree」フェアシェアアルゴリズムがデフォルトになっています。
 Please see the Fair Tree Fairshare documentation for further details.
詳細については、Fair TreeFairshareのドキュメントを参照してください。

"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.
19.05リリース以降、「クラシック」フェアシェアアルゴリズムはデフォルトではなくなり、PriorityFlags = NO_FAIR_TREEが明示的に設定されている場合にのみ使用されます。
 Docmentation describing that algorithm has been moved to a separate Classic Fairshare documentation page.
そのアルゴリズムを説明するドキュメントは、別のClassicFairshareドキュメントページに移動されました。

The sprio utility

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

Configuration

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

PriorityType
Set this value to "priority/multifactor" to enable the Multi-factor Job Priority Plugin.
この値を「priority / multifactor」に設定して、Multi-factor Job PriorityPluginを有効にします。
 The default value for this variable is "priority/basic" which enables simple FIFO scheduling.
この変数のデフォルト値は「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.
0に設定すると、減衰は適用されません。
 This is helpful if you want to enforce hard time limits per association.
これは、アソシエーションごとにハードタイム制限を適用する場合に役立ちます。
 If set to 0 PriorityUsageResetPeriod must be set to some interval.
0に設定する場合、PriorityUsageResetPeriodを一定の間隔に設定する必要があります。
 The unit is a time string (i.e. min, hr:min:00, days-hr:min:00, or days-hr).
単位は時間文字列です（つまり、min、hr：min：00、days-hr：min：00、またはdays-hr）。
 The default value is 7-0 (7 days).
デフォルト値は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.
この間隔で、アソシエーションの使用は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.
PriorityDecayHalfLifeが0に設定されている場合、減衰は発生せず、これがジョブの実行によって蓄積された使用量をリセットする唯一の方法です。
 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.
デフォルトではこれはオフになっており、クラスターで何も実行されないようにPriorityDecayHalfLifeオプションを使用することをお勧めしますが、スキーマがシステムで特定の時間のみを許可するように設定されている場合は、これがその方法です。
 Applicable only if PriorityType=priority/multifactor.
PriorityType = priority / multifactorの場合にのみ適用されます。
 The unit is a time string (i.e. NONE, NOW, DAILY, WEEKLY).
単位は時間文字列です（つまり、NONE、NOW、DAILY、WEEKLY）。
 The default is NONE.
デフォルトはNONEです。
  • NONE: Never clear historic usage.
    なし：過去の使用法をクリアしないでください。
     The default value.
    デフォルト値。
  • NOW: Clear the historic usage now.
    今：歴史的な使用法を今すぐクリアしてください。
     Executed at startup and reconfiguration time.
    起動時および再構成時に実行されます。
  • DAILY: Cleared every day at midnight.
    毎日：毎日深夜にクリアされます。
  • 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.
    毎年：毎年1日の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.
デフォルト設定はNOです。これにより、ノードサイズが大きくなり、ジョブサイズ係数が大きくなります。
 Setting this parameter to YES means that the smaller the job, the greater the job size factor will be.
このパラメーターを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).
単位は時間文字列です（つまり、min、hr：min：00、days-hr：min：00、またはdays-hr）。
 The default value is 7-0 (7 days).
デフォルト値は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.
    DEPTH_OBLIVIOUS：設定されている場合、優先度は通常の多因子計算と同様に計算されますが、ツリー内の関連付けの深さが優先度に悪影響を与えることはありません。
     This option automatically enables NO_FAIR_TREE.
    このオプションは、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.
    INCR_ONLY：設定されている場合、優先度の値は値が増加するだけです。
     Job priority will never decrease in value.
    仕事の優先順位が下がることはありません。
  • 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 'のMAXにすべてのグローバル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.
注：前述のように、6つの優先度係数の範囲は0.0から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.
そのため、PriorityWeightの項は、優先度係数のごくわずかな違いを解決するために、十分に高い値（たとえば、1000）に設定する必要がある場合があります。
 This is especially true with the fair-share factor, where two jobs may differ in priority by as little as .001.
これは、2つのジョブの優先度がわずか0.001だけ異なる可能性がある、フェアシェア係数の場合に特に当てはまります。
 (or even less!)
（またはそれ以下！）

Configuration Example

The following are sample slurm.conf file settings for the Multi-factor Job Priority Plugin.
以下は、Multi-factor Job PriorityPluginのサンプル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