Preemption
Slurm supports job preemption, the act of "stopping" one or more "low-priority"
jobs to let a "high-priority" job run.
Job preemption is implemented as a variation of Slurm's
Gang Scheduling logic.
When a job that can preempt others is allocated resources that are
already allocated to one or more jobs that could be preempted by the first job,
the preemptable job(s) are preempted.
Based on the configuration the preempted job(s) can be cancelled, or can be
requeued and started using other resources, or suspended and resumed once the
preemptor job completes, or can even share resources with the preemptor using
Gang Scheduling.
Slurmは、ジョブのプリエンプション、1つ以上の「優先度の低い」ジョブを「停止」して「優先度の高い」ジョブを実行させる行為をサポートしています。ジョブのプリエンプションは、Slurmのギャングスケジューリングロジックのバリエーションとして実装されます。他をプリエンプトできるジョブに、最初のジョブによってプリエンプトされる可能性がある1つ以上のジョブにすでに割り当てられているリソースが割り当てられている場合、プリエンプタブルジョブはプリエンプトされます。構成に基づいて、プリエンプトされたジョブをキャンセルしたり、他のリソースを使用してキューに再登録して開始したり、プリエンプタージョブが完了したら一時停止して再開したり、ギャングスケジューリングを使用してプリエンプターとリソースを共有したりできます。
The PriorityTier of the Partition of the job or its Quality Of Service (QOS)
can be used to identify which jobs can preempt or be preempted by other jobs.
Slurm offers the ability to configure the preemption mechanism used on a per
partition or per QOS basis.
For example, jobs in a low priority queue may get requeued,
while jobs in a medium priority queue may get suspended.
ジョブのパーティションのPriorityTierまたはそのサービスの品質（QOS）を使用して、他のジョブがプリエンプトまたはプリエンプトできるジョブを識別できます。Slurmは、パーティションごとまたはQOSベースで使用されるプリエンプションメカニズムを設定する機能を提供します。たとえば、優先度の低いキューにあるジョブは再キューイングされ、優先度が中程度のキューにあるジョブは一時停止される場合があります。
Configuration
There are several important configuration parameters relating to preemption:
プリエンプションに関連するいくつかの重要な構成パラメーターがあります。
-
SelectType: Slurm job preemption logic supports
nodes allocated by the select/linear plugin,
socket/core/CPU resources allocated by the select/cons_res and
select/cons_tres plugins, or select/cray_aries for Cray XC
systems without ALPS.
SelectType：Slurmジョブプリエンプションロジックは、select / linearプラグインによって割り当てられたノード、select / cons_resおよびselect / cons_tresプラグインによって割り当てられたソケット/コア/ CPUリソース、またはALPSのないCray XCシステムのselect / cray_ariesをサポートします。
-
SelectTypeParameter: Since resources may be getting over-allocated
with jobs (suspended jobs remain in memory), the resource selection
plugin should be configured to track the amount of memory used by each job to
ensure that memory page swapping does not occur.
When select/linear is chosen, we recommend setting
SelectTypeParameter=CR_Memory.
When select/cons_res or select/cons_tres are chosen, we recommend
including Memory as a resource (e.g. SelectTypeParameter=CR_Core_Memory).
SelectTypeParameter：リソースがジョブで割り当て超過になる可能性があるため（一時停止されたジョブはメモリ内に残ります）、メモリページスワッピングが発生しないように、各ジョブで使用されるメモリ量を追跡するようにリソース選択プラグインを構成する必要があります。select / linearを選択した場合は、SelectTypeParameter = CR_Memoryを設定することをお勧めします。select / cons_resまたはselect / cons_tresを選択する場合、リソースとしてメモリを含めることをお勧めします（例：SelectTypeParameter = CR_Core_Memory）。
NOTE: Unless PreemptMode=SUSPEND,GANG these memory management parameters are not critical.
注：PreemptMode = SUSPEND、GANGでない限り、これらのメモリ管理パラメーターは重要ではありません。
-
DefMemPerCPU: Since job requests may not explicitly specify
a memory requirement, we also recommend configuring
DefMemPerCPU (default memory per allocated CPU) or
DefMemPerNode (default memory per allocated node).
It may also be desirable to configure
MaxMemPerCPU (maximum memory per allocated CPU) or
MaxMemPerNode (maximum memory per allocated node) in slurm.conf.
Users can use the --mem or --mem-per-cpu option
at job submission time to specify their memory requirements.
NOTE: Unless PreemptMode=SUSPEND,GANG these memory management parameters are not critical.
DefMemPerCPU：ジョブリクエストでメモリ要件が明示的に指定されていない場合があるため、DefMemPerCPU（割り当てられたCPUごとのデフォルトメモリ）またはDefMemPerNode（割り当てられたノードごとのデフォルトメモリ）の構成もお勧めします。slurm.confでMaxMemPerCPU（割り当てられたCPUごとの最大メモリ）またはMaxMemPerNode（割り当てられたノードごとの最大メモリ）を構成することも望ましい場合があります。ユーザーは、ジョブの送信時に--memまたは--mem-per-cpuオプションを使用して、メモリ要件を指定できます。注：PreemptMode = SUSPEND、GANGでない限り、これらのメモリ管理パラメーターは重要ではありません。
-
GraceTime: Specifies a time period for a job to execute after
it is selected to be preempted. This option can be specified by partition or
QOS using the slurm.conf file or database respectively. This option is
only honored if PreemptMode=CANCEL. The GraceTime is specified in
seconds and the default value is zero, which results in no preemption delay.
Once a job has been selected for preemption, its end time is set to the
current time plus GraceTime. The job is immediately sent SIGCONT and
SIGTERM signals in order to provide notification of its imminent termination.
This is followed by the SIGCONT, SIGTERM and SIGKILL signal sequence upon
reaching its new end time.
GraceTime：ジョブがプリエンプトされるように選択された後に実行するジョブの期間を指定します。このオプションは、slurm.confファイルまたはデータベースをそれぞれ使用して、パーティションまたはQOSによって指定できます。このオプションは、PreemptMode = CANCELの場合にのみ有効です。GraceTimeは秒単位で指定され、デフォルト値はゼロであり、プリエンプションの遅延は発生しません。ジョブがプリエンプション用に選択されると、その終了時刻は現在の時刻とGraceTimeを足したものに設定されます。差し迫った終了の通知を提供するために、ジョブにはすぐにSIGCONTおよびSIGTERMシグナルが送信されます。その後、新しい終了時間に達すると、SIGCONT、SIGTERM、およびSIGKILLシグナルシーケンスが続きます。
-
JobAcctGatherType and JobAcctGatherFrequency: The "maximum data segment
size" and "maximum virtual memory size" system limits will be configured for
each job to ensure that the job does not exceed its requested amount of memory.
If you wish to enable additional enforcement of memory limits, configure job
accounting with the JobAcctGatherType and JobAcctGatherFrequency
parameters. When accounting is enabled and a job exceeds its configured memory
limits, it will be canceled in order to prevent it from adversely affecting
other jobs sharing the same resources.
NOTE: Unless PreemptMode=SUSPEND,GANG these memory management parameters are not critical.
JobAcctGatherTypeおよびJobAcctGatherFrequency：「最大データセグメントサイズ」および「最大仮想メモリサイズ」のシステム制限は、ジョブが要求されたメモリ量を超えないようにするために、各ジョブに対して構成されます。メモリ制限の追加の強制を有効にする場合は、JobAcctGatherTypeおよびJobAcctGatherFrequencyパラメーターを使用してジョブアカウンティングを構成します。アカウンティングが有効で、ジョブが構成されたメモリ制限を超えると、同じリソースを共有する他のジョブに悪影響を与えないようにするためにキャンセルされます。注：PreemptMode = SUSPEND、GANGでない限り、これらのメモリ管理パラメーターは重要ではありません。
-
PreemptMode: Mechanism used to preempt jobs or enable gang scheduling.
When the PreemptType parameter is set to enable preemption, the
PreemptMode in the main section of slurm.conf selects the default
mechanism used to preempt the preemptable jobs for the cluster.
PreemptMode：ジョブをプリエンプトするか、ギャングスケジューリングを有効にするために使用されるメカニズム。PreemptTypeパラメーターがプリエンプションを有効にするように設定されている場合、slurm.confのメインセクションのPreemptModeは、クラスターのプリエンプタブルジョブをプリエンプトするために使用されるデフォルトのメカニズムを選択します。
PreemptMode may be specified on a per partition basis to override this default value if PreemptType=preempt/partition_prio. Alternatively, it can be specified on a per QOS basis if PreemptType=preempt/qos. In either case, a valid default PreemptMode value must be specified for the cluster as a whole when preemption is enabled.
PreemptType = preempt / partition_prioの場合、PreemptModeをパーティションごとに指定して、このデフォルト値を上書きできます。または、PreemptType = preempt / qosの場合、QOSごとに指定できます。どちらの場合でも、プリエンプションが有効になっている場合、クラスター全体に対して有効なデフォルトのPreemptMode値を指定する必要があります。
The GANG option is used to enable gang scheduling independent of whether preemption is enabled (i.e. independent of PreemptType). It can be specified in addition to other PreemptMode settings, with the two options comma separated (e.g. PreemptMode=SUSPEND,GANG).
GANGオプションは、プリエンプションが有効かどうかに関係なく（つまり、PreemptTypeとは無関係に）ギャングスケジューリングを有効にするために使用されます。他のPreemptMode設定に加えて、2つのオプションをコンマで区切って指定できます（例：PreemptMode = SUSPEND、GANG）。
-
OFF: Is the default value and disables job preemption and gang
scheduling. It is only compatible with PreemptType=preempt/none.
OFF：これはデフォルト値であり、ジョブのプリエンプションとギャングスケジューリングを無効にします。PreemptType = preempt / noneとのみ互換性があります。
-
CANCEL: The preempted job will be cancelled.
CANCEL：プリエンプトされたジョブはキャンセルされます。
-
GANG: Enables gang scheduling (time slicing) of jobs in the same
partition, and allows the resuming of suspended jobs.
GANG：同じパーティション内のジョブのギャングスケジューリング（タイムスライシング）を有効にし、中断されたジョブの再開を許可します。
NOTE: Gang scheduling is performed independently for each partition, so if you only want time-slicing by OverSubscribe, without any preemption, then configuring partitions with overlapping nodes is not recommended. On the other hand, if you want to use PreemptType=preempt/partition_prio to allow jobs from higher PriorityTier partitions to Suspend jobs from lower PriorityTier partitions, then you will need overlapping partitions, and PreemptMode=SUSPEND,GANG to use Gang scheduler to resume the suspended job(s). In either case, time-slicing won't happen between jobs on different partitions.
注：ギャングスケジューリングはパーティションごとに独立して実行されるため、プリエンプションなしでOverSubscribeによるタイムスライスのみが必要な場合は、ノードが重複するパーティションを構成することはお勧めしません。一方、PreemptType = preempt / partition_prioを使用して、より高いPriorityTierパーティションからのジョブをより低いPriorityTierパーティションからの一時停止ジョブに許可する場合は、重複するパーティションと、PreemptMode = SUSPEND、GANGでGangスケジューラーを使用して再開する必要があります。一時停止されたジョブ。どちらの場合も、異なるパーティション上のジョブ間でタイムスライスは発生しません。
-
REQUEUE: Preempts jobs by requeuing them (if possible) or canceling
them. For jobs to be requeued they must have the "--requeue" sbatch option set
or the cluster wide JobRequeue parameter in slurm.conf must be set to 1.
REQUEUE：ジョブを再キューイング（可能な場合）またはキャンセルして、ジョブをプリエンプトします。ジョブを再キューイングするには、「-requeue」sbatchオプションを設定するか、slurm.confのクラスター全体のJobRequeueパラメーターを1に設定する必要があります。
-
SUSPEND: The preempted jobs will be suspended, and later the Gang
scheduler will resume them. Therefore, the SUSPEND preemption mode always
needs the GANG option to be specified at the cluster level.
Also, because the suspended jobs will still use memory on the allocated nodes,
Slurm needs to be able to track memory resources to be able to suspend jobs.
SUSPEND：プリエンプトされたジョブは一時停止され、後でGangスケジューラが再開します。したがって、SUSPENDプリエンプションモードでは、常にGANGオプションをクラスターレベルで指定する必要があります。また、中断されたジョブは割り当てられたノードのメモリを引き続き使用するため、Slurmはジョブを中断できるようにメモリリソースを追跡できる必要があります。
NOTE: Because gang scheduling is performed independently for each partition, if using PreemptType=preempt/partition_prio then jobs in higher PriorityTier partitions will suspend jobs in lower PriorityTier partitions to run on the released resources. Only when the preemptor job ends then the suspended jobs will be resumed by the Gang scheduler. If PreemptType=preempt/qos is configured and if the preempted job(s) and the preemptor job from are on the same partition, then they will share resources with the Gang scheduler (time-slicing). If not (i.e. if the preemptees and preemptor are on different partitions) then the preempted jobs will remain suspended until the preemptor ends.
注：ギャングスケジューリングはパーティションごとに独立して実行されるため、PreemptType = preempt / partition_prioを使用すると、高いPriorityTierパーティションのジョブは、低いPriorityTierパーティションのジョブを中断して、解放されたリソースで実行されます。プリエンプタージョブが終了した場合のみ、中断されたジョブはGangスケジューラーによって再開されます。PreemptType = preempt / qosが構成されていて、プリエンプトされたジョブとプリエンプタージョブが同じパーティションにある場合、それらはGangスケジューラーとリソースを共有します（タイムスライシング）。そうでない場合（つまり、プリエンプティとプリエンプタが異なるパーティションにある場合）、プリエンプタが終了するまで、プリエンプションされたジョブは中断されたままになります。
-
OFF: Is the default value and disables job preemption and gang
scheduling. It is only compatible with PreemptType=preempt/none.
-
PreemptType: Specifies the plugin used to identify which jobs can be
preempted in order to start a pending job.
PreemptType：保留中のジョブを開始するためにプリエンプトできるジョブを識別するために使用されるプラグインを指定します。
- preempt/none: Job preemption is disabled (default).
preempt / none：ジョブのプリエンプションは無効です（デフォルト）。 - preempt/partition_prio: Job preemption is based upon partition
PriorityTier. Jobs in higher PriorityTier partitions may preempt jobs
from lower PriorityTier partitions. This is not compatible with
PreemptMode=OFF.
preempt / partition_prio：ジョブのプリエンプションは、パーティションPriorityTierに基づいています。より高いPriorityTierパーティション内のジョブは、より低いPriorityTierパーティションからジョブをプリエンプトする場合があります。これはPreemptMode = OFFと互換性がありません。 - preempt/qos: Job preemption rules are specified by Quality Of
Service (QOS) specifications in the Slurm database. This option is not
compatible with PreemptMode=OFF. A configuration of
PreemptMode=SUSPEND is only supported by the
SelectType=select/cons_res and SelectType=select/cons_tres
plugins.
preempt / qos：ジョブのプリエンプションルールは、Slurmデータベースのサービス品質（QOS）仕様で指定されています。このオプションはPreemptMode = OFFと互換性がありません。PreemptMode = SUSPENDの構成は、SelectType = select / cons_resおよびSelectType = select / cons_tresプラグインでのみサポートされています。
See the sacctmgr man page to configure the options of preempt/qos.
preempt / qosのオプションを構成するには、sacctmgrのマニュアルページを参照してください。
- preempt/none: Job preemption is disabled (default).
-
PreemptExemptTime: Specifies minimum run time of jobs before they are
considered for preemption. Unlike GraceTime, this is honored for all
values of PreemptMode. It is specified as a time string:
A time of -1 disables the option, equivalent to 0. Acceptable time formats
include "minutes", "minutes:seconds", "hours:minutes:seconds", "days\-hours",
"days\-hours:minutes", and "days\-hours:minutes:seconds".
PreemptEligibleTime is shown in the output of "scontrol show job <job id>"
PreemptExemptTime：ジョブがプリエンプションと見なされる前のジョブの最小実行時間を指定します。GraceTimeとは異なり、これはPreemptModeのすべての値に適用されます。時刻文字列として指定されます。時刻-1は0に相当するオプションを無効にします。許容される時刻形式には、「分」、「分：秒」、「時：分：秒」、「日-時間」、 「days -hours：minutes」、および「days -hours：minutes：seconds」。PreemptEligibleTimeは、「scontrol show jobの出力に表示されます。」
-
PriorityTier: Configure the partition's PriorityTier setting
relative to other partitions to control the preemptive behavior when
PreemptType=preempt/partition_prio.
This option is not relevant if PreemptType=preempt/qos.
If two jobs from two
different partitions are allocated to the same resources, the job in the
partition with the greater PriorityTier value will preempt the job in the
partition with the lesser PriorityTier value. If the PriorityTier
values of the two partitions are equal then no preemption will occur. The
default PriorityTier value is 1.
PriorityTier：他のパーティションに対するパーティションのPriorityTier設定を構成して、PreemptType = preempt / partition_prioの場合のプリエンプティブ動作を制御します。PreemptType = preempt / qosの場合、このオプションは関係ありません。2つの異なるパーティションからの2つのジョブが同じリソースに割り当てられている場合、PriorityTier値が大きいパーティション内のジョブが、PriorityTier値が小さいパーティション内のジョブよりも優先されます。2つのパーティションのPriorityTier値が等しい場合、プリエンプションは発生しません。デフォルトのPriorityTier値は1です。
-
OverSubscribe: Configure the partition's OverSubscribe setting to
FORCE for all partitions in which job preemption using a suspend/resume
mechanism is used.
The FORCE option supports an additional parameter that controls
how many jobs can oversubscribe a compute resource (FORCE[:max_share]). By
default the max_share value is 4. In order to preempt jobs (and not gang
schedule them), always set max_share to 1. To allow up to 2 jobs from this
partition to be allocated to a common resource (and gang scheduled), set
OverSubscribe=FORCE:2.
OverSubscribe：サスペンド/再開メカニズムを使用したジョブのプリエンプションが使用されるすべてのパーティションに対して、パーティションのOverSubscribe設定をFORCEに構成します。FORCEオプションは、計算リソースをオーバーサブスクライブできるジョブの数を制御する追加のパラメーターをサポートします（FORCE [：max_share]）。デフォルトでは、max_share値は4です。ジョブをプリエンプト（ギャングスケジュールしない）するには、常にmax_shareを1に設定します。このパーティションから最大2つのジョブを共通リソースに割り当てる（ギャングスケジュールする）には、次のように設定します。 OverSubscribe = FORCE：2。
NOTE: PreemptType=preempt/qos will permit one additional job to be run on the partition if started due to job preemption. For example, a configuration of OverSubscribe=FORCE:1 will only permit one job per resource normally, but a second job can be started if done so through preemption based upon QOS.
注：PreemptType = preempt / qosを指定すると、ジョブのプリエンプションが原因で開始された場合、パーティションで1つの追加ジョブを実行できます。たとえば、OverSubscribe = FORCE：1の構成では、通常、リソースごとに1つのジョブしか許可されませんが、QOSに基づくプリエンプションを介してそうする場合、2番目のジョブを開始できます。
To enable preemption after making the configuration changes described above,
restart Slurm if it is already running. Any change to the plugin settings in
Slurm requires a full restart of the daemons. If you just change the partition
PriorityTier or OverSubscribe setting, this can be updated with
scontrol reconfig.
上記の設定変更後にプリエンプションを有効にするには、Slurmがすでに実行されている場合は再起動します。Slurmでプラグイン設定を変更すると、デーモンを完全に再起動する必要があります。パーティションのPriorityTierまたはOverSubscribe設定を変更するだけの場合、これはscontrol reconfigで更新できます。
If a job request restricts Slurm's ability to run jobs from multiple users or
accounts on a node by using the "--exclusive=user" or "--exclusive=mcs" job
options, that may prevent preemption of jobs to start jobs with preempting
privileges. If preemption is used, it is generally advisable to disable the
"--exclusive=user" and "--exclusive=mcs" job options by using a job_submit
plugin (set the value of "shared" to "NO_VAL16").
ジョブリクエストが「--exclusive = user」または「--exclusive = mcs」ジョブオプションを使用して、ノード上の複数のユーザーまたはアカウントからジョブを実行するSlurmの機能を制限している場合、ジョブのプリエンプションが妨げられ、プリエンプションを使用してジョブを開始できます。特権。プリエンプションを使用する場合、job_submitプラグインを使用して「--exclusive = user」および「--exclusive = mcs」ジョブオプションを無効にすることをお勧めします（「shared」の値を「NO_VAL16」に設定します）。
For heterogeneous job to be considered for preemption all components
must be eligible for preemption. When a heterogeneous job is to be preempted
the first identified component of the job with the highest order PreemptMode
(SUSPEND (highest), REQUEUE, CANCEL (lowest)) will be
used to set the PreemptMode for all components. The GraceTime and user
warning signal for each component of the heterogeneous job remain unique.
異種ジョブがプリエンプションの対象となるには、すべてのコンポーネントがプリエンプションの対象である必要があります。異種ジョブをプリエンプトする場合、最高の順序PreemptMode（SUSPEND（最高）、REQUEUE、CANCEL（最低））を持つジョブの最初に識別されたコンポーネントを使用して、すべてのコンポーネントのPreemptModeを設定します。異機種混合ジョブの各コンポーネントのGraceTimeおよびユーザー警告信号は、一意のままです。
Preemption Design and Operation
The SelectType plugin will identify resources where a pending job can
begin execution. When PreemptMode is configured to CANCEL,
SUSPEND or REQUEUE, the select plugin will also preempt running
jobs as needed to initiate the pending job. When
PreemptMode=SUSPEND,GANG the select plugin will initiate the pending
job and rely upon the gang scheduling logic to perform job suspend and resume,
as described below.
SelectTypeプラグインは、保留中のジョブが実行を開始できるリソースを識別します。PreemptModeがCANCEL、SUSPEND、またはREQUEUEに構成されている場合、selectプラグインは、保留中のジョブを開始するために必要に応じて、実行中のジョブをプリエンプトします。PreemptMode = SUSPEND、GANGの場合、選択プラグインは保留中のジョブを開始し、以下で説明するように、ギャングスケジューリングロジックに依存してジョブの中断と再開を実行します。
The select plugin is passed an ordered list of preemptable jobs to consider for
each pending job which is a candidate to start.
This list is sorted by either:
選択プラグインには、開始候補の保留中の各ジョブについて検討するためのプリエンプティブルジョブの順序付きリストが渡されます。このリストは次のいずれかでソートされます。
- QOS priority,
QOS優先度 - Partition priority and job size (to favor preempting smaller jobs), or
パーティションの優先順位とジョブサイズ（小さいジョブのプリエンプションを優先するため）、または - Job start time (with SchedulerParameters=preempt_youngest_first).
ジョブの開始時刻（SchedulerParameters = preempt_youngest_firstを使用）。
The select plugin will determine if the pending job can start without preempting
any jobs and if so, starts the job using available resources.
Otherwise, the select plugin will simulate the preemption of each job in the
priority ordered list and test if the job can be started after each preemption.
selectプラグインは、保留中のジョブをプリエンプトせずに開始できるかどうかを判断し、可能であれば、利用可能なリソースを使用してジョブを開始します。それ以外の場合、selectプラグインは優先順位付きリストの各ジョブのプリエンプションをシミュレートし、各プリエンプションの後にジョブを開始できるかどうかをテストします。
Once the job can be started, the higher priority jobs in the preemption queue
will not be considered, but the jobs to be preempted in the original list may
be sub-optimal.
ジョブを開始できるようになると、プリエンプションキュー内の優先度の高いジョブは考慮されませんが、元のリストでプリエンプトされるジョブは最適ではない可能性があります。
For example, to start an 8 node job, the ordered preemption candidates may be
2 node, 4 node and 8 node.
Preempting all three jobs would allow the pending job to start, but by reordering
the preemption candidates it is possible to start the pending job after
preempting only one job.
たとえば、8ノードのジョブを開始するために、順序付けされたプリエンプションの候補は、2ノード、4ノード、8ノードの場合があります。3つすべてのジョブをプリエンプトすると、保留中のジョブを開始できますが、プリエンプションの候補を並べ替えることで、1つのジョブだけをプリエンプトした後で、保留中のジョブを開始できます。
To address this issue, the preemption candidates are re-ordered with the final
job requiring preemption placed first in the list and all of the other jobs
to be preempted ordered by the number of nodes in their allocation which overlap
the resources selected for the pending job.
In the example above, the 8 node job would be moved to the first position in
the list.
この問題に対処するために、プリエンプション候補は、リストの最初に配置されたプリエンプションを必要とする最後のジョブと、保留中のジョブ用に選択されたリソースと重複する割り当て内のノードの数によってプリエンプトされる他のすべてのジョブで並べ替えられます。上記の例では、8ノードのジョブはリストの最初の位置に移動します。
The process of simulating the preemption of each job in the priority ordered
list will then be repeated for the final decision of which jobs to preempt.
This two stage process may preempt jobs which are not strictly in preemption
priority order, but fewer jobs will be preempted than otherwise required.
See the SchedulerParameters configuration parameter options of
preempt_reorder_count and preempt_strict_order for preemption
tuning parameters.
次に、優先順位付きリスト内の各ジョブのプリエンプションをシミュレートするプロセスが、どのジョブをプリエンプトするかの最終決定のために繰り返されます。この2段階のプロセスは、厳密に優先使用優先順位にないジョブを優先使用する場合がありますが、それ以外の場合よりも少ないジョブが優先使用されます。プリエンプション調整パラメーターについては、preempt_reorder_countおよびpreempt_strict_orderのSchedulerParameters構成パラメーターオプションを参照してください。
When enabled, the gang scheduling logic (which is also supports job
preemption) keeps track of the resources allocated to all jobs.
For each partition an "active bitmap" is maintained that tracks all
concurrently running jobs in the Slurm cluster.
有効にすると、ギャングスケジューリングロジック（ジョブのプリエンプションもサポートされます）がすべてのジョブに割り当てられたリソースを追跡します。各パーティションについて、Slurmクラスターで同時に実行されているすべてのジョブを追跡する「アクティブなビットマップ」が維持されます。
Each partition also maintains a job list for that partition, and a list of
"shadow" jobs.
The "shadow" jobs are high priority job allocations that "cast shadows" on the
active bitmaps of the low priority jobs.
Jobs caught in these "shadows" will be preempted.
各パーティションは、そのパーティションのジョブリストと「シャドウ」ジョブのリストも保持します。「シャドウ」ジョブは、優先度の低いジョブのアクティブなビットマップに「シャドウをキャスト」する優先度の高いジョブ割り当てです。これらの「影」に捕らえられた仕事は先制されます。
Each time a new job is allocated to resources in a partition and begins
running, the gang scheduler adds a "shadow" of this job to all lower priority
partitions.
新しいジョブがパーティション内のリソースに割り当てられて実行を開始するたびに、ギャングスケジューラはこのジョブの「シャドウ」をすべての優先順位の低いパーティションに追加します。
The active bitmap of these lower priority partitions are then rebuilt, with the shadow jobs added first.
Any existing jobs that were replaced by one or more "shadow" jobs are
suspended (preempted). Conversely, when a high priority running job completes,
its "shadow" goes away and the active bitmaps of the lower priority
partitions are rebuilt to see if any suspended jobs can be resumed.
次に、これらの優先度の低いパーティションのアクティブなビットマップが再構築され、シャドウジョブが最初に追加されます。1つ以上の「シャドウ」ジョブによって置き換えられた既存のジョブはすべて一時停止（プリエンプト）されます。逆に、優先度の高い実行中のジョブが完了すると、その「シャドウ」が消え、優先度の低いパーティションのアクティブなビットマップが再構築され、中断されているジョブを再開できるかどうかが確認されます。
The gang scheduler plugin is designed to be reactive to the resource
allocation decisions made by the "select" plugins.
ギャングスケジューラプラグインは、「選択」プラグインによるリソース割り当ての決定に反応するように設計されています。
The "select" plugins have been enhanced to recognize when job preemption has
been configured, and to factor in the priority of each partition when selecting resources for a job.
When choosing resources for each job, the selector avoids resources that are
in use by other jobs (unless sharing has been configured, in which case it
does some load-balancing).
「select」プラグインは、ジョブのプリエンプションがいつ設定されたかを認識し、ジョブのリソースを選択するときに各パーティションの優先度を考慮するように拡張されました。各ジョブのリソースを選択するとき、セレクターは、他のジョブで使用されているリソースを回避します（共有が構成されていない場合、その場合、負荷分散が行われます）。
However, when job preemption is enabled, the select plugins may choose
resources that are already in use by jobs from partitions with a lower
priority setting, even when sharing is disabled in those partitions.
ただし、ジョブのプリエンプションが有効になっている場合、選択プラグインは、それらのパーティションで共有が無効になっている場合でも、優先度の低い設定のパーティションからジョブによってすでに使用されているリソースを選択する場合があります。
This leaves the gang scheduler in charge of controlling which jobs should run
on the over-allocated resources.
If PreemptMode=SUSPEND, jobs are suspended using the same internal
functions that support scontrol suspend and scontrol resume.
A good way to observe the operation of the gang scheduler is by running
squeue -i<time> in a terminal window.
これにより、ギャングスケジューラは、割り当て超過のリソースで実行するジョブの制御を担当します。PreemptMode = SUSPENDの場合、scontrol suspendおよびscontrol resumeをサポートする同じ内部関数を使用してジョブが一時停止されます。ギャングスケジューラの動作を監視する良い方法は、squeue -iを実行することです。 ターミナルウィンドウ。
Limitations of Preemption During Backfill Scheduling
For performance reasons, the backfill scheduler reserves whole nodes for jobs,
not partial nodes. If during backfill scheduling a job preempts one or more
other jobs, the whole nodes for those preempted jobs are reserved for the
preemptor job, even if the preemptor job requested fewer resources than that.
These reserved nodes aren't available to other jobs during that backfill
cycle, even if the other jobs could fit on the nodes. Therefore, jobs may
preempt more resources during a single backfill iteration than they requested.
パフォーマンス上の理由から、バックフィルスケジューラは、部分的なノードではなく、ノード全体をジョブ用に予約します。バックフィルスケジューリング中にジョブが1つ以上の他のジョブをプリエンプトする場合、プリエンプタージョブがそれよりも少ないリソースを要求した場合でも、それらのプリエンプトされたジョブのノード全体がプリエンプタージョブ用に予約されます。これらの予約済みノードは、他のジョブがノードに収まる場合でも、そのバックフィルサイクル中は他のジョブで使用できません。したがって、ジョブは、1回のバックフィルの反復中に、要求より多くのリソースをプリエンプトする可能性があります。
A Simple Example
The following example is configured with select/linear and
PreemptMode=SUSPEND,GANG.
次の例は、select / linearおよびPreemptMode = SUSPEND、GANGで構成されています。
This example takes place on a cluster of 5 nodes:
この例は、5つのノードのクラスターで行われます。
[user@n16 ~]$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST active* up infinite 5 idle n[12-16] hipri up infinite 5 idle n[12-16]
Here are the Partition settings:
パーティション設定は次のとおりです。
[user@n16 ~]$ grep PartitionName /shared/slurm/slurm.conf PartitionName=DEFAULT OverSubscribe=FORCE:1 Nodes=n[12-16] PartitionName=active PriorityTier=1 Default=YES PartitionName=hipri PriorityTier=2
The runit.pl script launches a simple load-generating app that runs
for the given number of seconds. Submit 5 single-node runit.pl jobs to
run on all nodes:
runit.plスクリプトは、指定された秒数実行される単純な負荷生成アプリを起動します。すべてのノードで実行する5つの単一ノードrunit.plジョブを送信します。
[user@n16 ~]$ sbatch -N1 ./runit.pl 300 sbatch: Submitted batch job 485 [user@n16 ~]$ sbatch -N1 ./runit.pl 300 sbatch: Submitted batch job 486 [user@n16 ~]$ sbatch -N1 ./runit.pl 300 sbatch: Submitted batch job 487 [user@n16 ~]$ sbatch -N1 ./runit.pl 300 sbatch: Submitted batch job 488 [user@n16 ~]$ sbatch -N1 ./runit.pl 300 sbatch: Submitted batch job 489 [user@n16 ~]$ squeue -Si JOBID PARTITION NAME USER ST TIME NODES NODELIST 485 active runit.pl user R 0:06 1 n12 486 active runit.pl user R 0:06 1 n13 487 active runit.pl user R 0:05 1 n14 488 active runit.pl user R 0:05 1 n15 489 active runit.pl user R 0:04 1 n16
Now submit a short-running 3-node job to the hipri partition:
次に、短期実行の3ノードジョブをHipriパーティションに送信します。
[user@n16 ~]$ sbatch -N3 -p hipri ./runit.pl 30 sbatch: Submitted batch job 490 [user@n16 ~]$ squeue -Si JOBID PARTITION NAME USER ST TIME NODES NODELIST 485 active runit.pl user S 0:27 1 n12 486 active runit.pl user S 0:27 1 n13 487 active runit.pl user S 0:26 1 n14 488 active runit.pl user R 0:29 1 n15 489 active runit.pl user R 0:28 1 n16 490 hipri runit.pl user R 0:03 3 n[12-14]
Job 490 in the hipri partition preempted jobs 485, 486, and 487 from
the active partition. Jobs 488 and 489 in the active partition
remained running.
Hipriパーティションのジョブ490は、アクティブパーティションのジョブ485、486、および487をプリエンプトしました。アクティブパーティションのジョブ488および489は実行されたままでした。
This state persisted until job 490 completed, at which point the preempted jobs
were resumed:
この状態は、ジョブ490が完了するまで続き、その時点でプリエンプトされたジョブが再開されました。
[user@n16 ~]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 485 active runit.pl user R 0:30 1 n12 486 active runit.pl user R 0:30 1 n13 487 active runit.pl user R 0:29 1 n14 488 active runit.pl user R 0:59 1 n15 489 active runit.pl user R 0:58 1 n16
Another Example
In this example we have three different partitions using three different
job preemption mechanisms.
この例では、3つの異なるジョブプリエンプションメカニズムを使用する3つの異なるパーティションがあります。
# Excerpt from slurm.conf PartitionName=low Nodes=linux Default=YES OverSubscribe=NO PriorityTier=10 PreemptMode=requeue PartitionName=med Nodes=linux Default=NO OverSubscribe=FORCE:1 PriorityTier=20 PreemptMode=suspend PartitionName=hi Nodes=linux Default=NO OverSubscribe=FORCE:1 PriorityTier=30 PreemptMode=off
$ sbatch tmp
Submitted batch job 94
$ sbatch -p med tmp
Submitted batch job 95
$ sbatch -p hi tmp
Submitted batch job 96
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
96 hi tmp moe R 0:04 1 linux
94 low tmp moe PD 0:00 1 (Resources)
95 med tmp moe S 0:02 1 linux
(after job 96 completes)
$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
94 low tmp moe PD 0:00 1 (Resources)
95 med tmp moe R 0:24 1 linux
Another Example
In this example we have one partition on which we want to execute only one
job per resource (e.g. core) at a time except when a job submitted to the
partition from a high priority Quality Of Service (QOS) is submitted. In that
case, we want that second high priority job to be started and be gang scheduled
with the other jobs on overlapping resources.
この例では、優先度の高いサービス品質（QOS）からパーティションに送信されたジョブが送信された場合を除き、リソース（コアなど）ごとに一度に1つのジョブのみを実行するパーティションが1つあります。その場合は、2番目に優先度の高いジョブを開始し、重複するリソースで他のジョブとギャングスケジュールを設定します。
# Excerpt from slurm.conf PreemptMode=Suspend,Gang PreemptType=preempt/qos PartitionName=normal Nodes=linux Default=NO OverSubscribe=FORCE:1
Future Ideas
More intelligence in the select plugins: This implementation of
preemption relies on intelligent job placement by the select plugins.
選択プラグインのインテリジェンスの強化：プリエンプションのこの実装は、選択プラグインによるインテリジェントジョブ配置に依存しています。
Take the following example:
次の例を見てください。
[user@n8 ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
active* up infinite 5 idle n[1-5]
hipri up infinite 5 idle n[1-5]
[user@n8 ~]$ sbatch -N1 -n2 ./sleepme 60
sbatch: Submitted batch job 17
[user@n8 ~]$ sbatch -N1 -n2 ./sleepme 60
sbatch: Submitted batch job 18
[user@n8 ~]$ sbatch -N1 -n2 ./sleepme 60
sbatch: Submitted batch job 19
[user@n8 ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
17 active sleepme cholmes R 0:03 1 n1
18 active sleepme cholmes R 0:03 1 n2
19 active sleepme cholmes R 0:02 1 n3
[user@n8 ~]$ sbatch -N3 -n6 -p hipri ./sleepme 20
sbatch: Submitted batch job 20
[user@n8 ~]$ squeue -Si
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
17 active sleepme cholmes S 0:16 1 n1
18 active sleepme cholmes S 0:16 1 n2
19 active sleepme cholmes S 0:15 1 n3
20 hipri sleepme cholmes R 0:03 3 n[1-3]
[user@n8 ~]$ sinfo
PARTITION AVAIL TIMELIMIT NODES STATE NODELIST
active* up infinite 3 alloc n[1-3]
active* up infinite 2 idle n[4-5]
hipri up infinite 3 alloc n[1-3]
hipri up infinite 2 idle n[4-5]
It would be more ideal if the "hipri" job were placed on nodes n[3-5], which
would allow jobs 17 and 18 to continue running. However, a new "intelligent"
algorithm would have to include factors such as job size and required nodes in
order to support ideal placements such as this, which can quickly complicate
the design. Any and all help is welcome here!
「hipri」ジョブをノードn [3-5]に配置すると、ジョブ17と18の実行を継続できるので、より理想的です。ただし、新しい「インテリジェント」アルゴリズムには、このような理想的な配置をサポートするために、ジョブサイズや必要なノードなどの要素を含める必要があり、設計がすぐに複雑になる可能性があります。ここでどんな助けも歓迎します！
Last modified 10 April 2020