Preemption

Slurm supports job preemption, the act of "stopping" one or more "low-priority" jobs to let a "high-priority" job run.
Slurmは、ジョブのプリエンプション、つまり1つ以上の「優先度の低い」ジョブを「停止」して「優先度の高い」ジョブを実行させる動作をサポートします。
 Job preemption is implemented as a variation of Slurm's Gang Scheduling logic.
ジョブプリエンプションは、Slurmのギャングスケジューリングロジックのバリエーションとして実装されています。
 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.
他のジョブをプリエンプトできるジョブに、最初のジョブによってプリエンプトされる可能性のある1つ以上のジョブにすでに割り当てられているリソースが割り当てられると、プリエンプト可能なジョブがプリエンプトされます。
 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.
構成に基づいて、プリエンプトされたジョブをキャンセルしたり、キューに入れ直して他のリソースを使用して開始したり、プリエンプタージョブが完了したら一時停止して再開したり、ギャングスケジューリングを使用してプリエンプターとリソースを共有したりすることもできます。

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.
ジョブのパーティションのPriorityTierまたはそのサービス品質（QOS）を使用して、どのジョブをプリエンプトできるか、または他のジョブによってプリエンプトできるかを識別できます。
 Slurm offers the ability to configure the preemption mechanism used on a per partition or per QOS basis.
Slurmは、パーティションごとまたはQOSごとに使用されるプリエンプションメカニズムを構成する機能を提供します。
 For example, jobs in a low priority queue may get requeued, while jobs in a medium priority queue may get suspended.
たとえば、優先度の低いキューのジョブは再キューイングされ、優先度の高いキューのジョブは一時停止される場合があります。

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のないCrayXCシステムの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.
    SelectTypeParameter：リソースがジョブで過剰に割り当てられる可能性があるため（中断されたジョブはメモリに残ります）、リソース選択プラグインは、メモリページのスワッピングが発生しないように、各ジョブで使用されるメモリの量を追跡するように構成する必要があります。
     When select/linear is chosen, we recommend setting SelectTypeParameter=CR_Memory.
    select / linearを選択する場合は、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).
    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).
    DefMemPerCPU：ジョブ要求はメモリ要件を明示的に指定しない場合があるため、DefMemPerCPU（割り当てられたCPUごとのデフォルトメモリ）またはDefMemPerNode（割り当てられたノードごとのデフォルトメモリ）を構成することもお勧めします。
     It may also be desirable to configure MaxMemPerCPU (maximum memory per allocated CPU) or MaxMemPerNode (maximum memory per allocated node) in slurm.conf.
    slurm.confでMaxMemPerCPU（割り当てられたCPUあたりの最大メモリ）またはMaxMemPerNode（割り当てられたノードあたりの最大メモリ）を構成することも望ましい場合があります。
     Users can use the --mem or --mem-per-cpu option at job submission time to specify their memory requirements.
    ユーザーは、ジョブの送信時に--memまたは--mem-per-cpuオプションを使用して、メモリ要件を指定できます。
    NOTE: Unless PreemptMode=SUSPEND,GANG these memory management parameters are not critical.
    注：PreemptMode = SUSPEND、GANGでない限り、これらのメモリ管理パラメータは重要ではありません。
  • GraceTime: Specifies a time period for a job to execute after it is selected to be preempted.
    GraceTime：プリエンプトするように選択された後、ジョブが実行される期間を指定します。
     This option can be specified by partition or QOS using the slurm.conf file or database respectively.
    このオプションは、slurm.confファイルまたはデータベースをそれぞれ使用してパーティションまたはQOSで指定できます。
     This option is only honored if PreemptMode=CANCEL.
    このオプションは、PreemptMode = CANCELの場合にのみ適用されます。
     The GraceTime is specified in seconds and the default value is zero, which results in no preemption delay.
    GraceTimeは秒単位で指定され、デフォルト値はゼロです。これにより、プリエンプションの遅延は発生しません。
     Once a job has been selected for preemption, its end time is set to the current time plus GraceTime.
    ジョブがプリエンプション用に選択されると、その終了時刻は現在の時刻にGraceTimeを加えたものに設定されます。
     The job is immediately sent SIGCONT and SIGTERM signals in order to provide notification of its imminent termination.
    ジョブは、その差し迫った終了の通知を提供するために、すぐにSIGCONTおよびSIGTERMシグナルを送信されます。
     This is followed by the SIGCONT, SIGTERM and SIGKILL signal sequence upon reaching its new end time.
    これに続いて、新しい終了時刻に達すると、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.
    JobAcctGatherTypeおよびJobAcctGatherFrequency：「最大データセグメントサイズ」および「最大仮想メモリサイズ」のシステム制限は、ジョブが要求されたメモリ量を超えないように、ジョブごとに構成されます。
     If you wish to enable additional enforcement of memory limits, configure job accounting with the JobAcctGatherType and JobAcctGatherFrequency parameters.
    メモリ制限の追加の適用を有効にする場合は、JobAcctGatherTypeパラメーターとJobAcctGatherFrequencyパラメーターを使用してジョブアカウンティングを構成します。
     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.
    注：PreemptMode = SUSPEND、GANGでない限り、これらのメモリ管理パラメータは重要ではありません。
  • PreemptMode: Mechanism used to preempt jobs or enable gang scheduling.
    PreemptMode：ジョブをプリエンプトしたり、ギャングスケジューリングを有効にしたりするために使用されるメカニズム。
     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.
    PreemptTypeパラメーターがプリエンプションを有効にするように設定されている場合、slurm.confのメインセクションのPreemptModeは、クラスターのプリエンプション可能なジョブをプリエンプションするために使用されるデフォルトのメカニズムを選択します。
    PreemptMode may be specified on a per partition basis to override this default value if PreemptType=preempt/partition_prio.
    PreemptType = preempt / partition_prioの場合、PreemptModeをパーティションごとに指定して、このデフォルト値をオーバーライドできます。
     Alternatively, it can be specified on a per QOS basis if PreemptType=preempt/qos.
    または、PreemptType = preempt / qosの場合、QOSごとに指定できます。
     In either case, a valid default PreemptMode value must be specified for the cluster as a whole when preemption is enabled.
    いずれの場合も、プリエンプションが有効になっている場合は、クラスター全体に対して有効なデフォルトのPreemptMode値を指定する必要があります。
    The GANG option is used to enable gang scheduling independent of whether preemption is enabled (i.e. independent of PreemptType).
    GANGオプションは、プリエンプションが有効かどうかに関係なく（つまり、PreemptTypeに関係なく）ギャングスケジューリングを有効にするために使用されます。
     It can be specified in addition to other PreemptMode settings, with the two options comma separated (e.g. PreemptMode=SUSPEND,GANG).
    他のPreemptMode設定に加えて、2つのオプションをコンマで区切って指定できます（例：PreemptMode = SUSPEND、GANG）。
    • OFF: Is the default value and disables job preemption and gang scheduling.
      OFF：デフォルト値であり、ジョブのプリエンプションとギャングスケジューリングを無効にします。
       It is only compatible with PreemptType=preempt/none.
      PreemptType = preempt / noneとのみ互換性があります。
    • CANCEL: The preempted job will be cancelled.
      キャンセル：プリエンプトされたジョブはキャンセルされます。
    • 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.
      注：ギャングスケジューリングはパーティションごとに個別に実行されるため、プリエンプションなしでOverSubscribeによるタイムスライスのみが必要な場合は、ノードが重複するパーティションを構成することはお勧めしません。
       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).
      一方、PreemptType = preempt / partition_prioを使用して、優先度の高いパーティションからのジョブを優先度の低いパーティションからのジョブを一時停止できるようにする場合は、パーティションをオーバーラップさせる必要があります。PreemptMode= SUSPEND、GANGを使用して、ギャングスケジューラを使用して再開します。中断されたジョブ。
       In either case, time-slicing won't happen between jobs on different partitions.
      いずれの場合も、異なるパーティション上のジョブ間でタイムスライスは発生しません。
    • REQUEUE: Preempts jobs by requeuing them (if possible) or canceling them.
      REQUEUE：ジョブを再キューイング（可能な場合）またはキャンセルすることにより、ジョブをプリエンプトします。
       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」スバッチオプションを設定するか、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.
      したがって、SUSPENDプリエンプションモードでは、常にGANGオプションをクラスターレベルで指定する必要があります。
       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.
      また、中断されたジョブは割り当てられたノードのメモリを引き続き使用するため、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.
      注：ギャングスケジューリングはパーティションごとに個別に実行されるため、PreemptType = preempt / partition_prioを使用すると、PriorityTierの高いパーティションのジョブは、解放されたリソースで実行するためにPriorityTierの低いパーティションのジョブを一時停止します。
       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).
      PreemptType = preempt / qosが構成されていて、プリエンプトされたジョブとからのプリエンプタージョブが同じパーティション上にある場合、それらはギャングスケジューラーとリソースを共有します（タイムスライス）。
       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: 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/partition_prio: Job preemption is based upon partition PriorityTier.
      preempt / partition_prio：ジョブのプリエンプションはパーティションPriorityTierに基づいています。
       Jobs in higher PriorityTier partitions may preempt jobs from lower PriorityTier partitions.
      PriorityTierの高いパーティションのジョブは、PriorityTierの低いパーティションからジョブをプリエンプトする場合があります。
       This is not compatible with PreemptMode=OFF.
      これはPreemptMode = OFFと互換性がありません。
    • preempt/qos: Job preemption rules are specified by Quality Of Service (QOS) specifications in the Slurm database.
      preempt / qos：ジョブプリエンプションルールは、SlurmデータベースのQuality Of Service（QOS）仕様によって指定されます。
       This option is not compatible with PreemptMode=OFF.
      このオプションは、PreemptMode = OFFと互換性がありません。
       A configuration of PreemptMode=SUSPEND is only supported by the SelectType=select/cons_res and SelectType=select/cons_tres plugins.
      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のマニュアルページを参照してください。
  • PreemptExemptTime: Specifies minimum run time of jobs before they are considered for preemption.
    PreemptExemptTime：プリエンプションの対象と見なされる前のジョブの最小実行時間を指定します。
     Unlike GraceTime, this is honored for all values of PreemptMode.
    GraceTimeとは異なり、これはPreemptModeのすべての値に適用されます。
     It is specified as a time string: A time of -1 disables the option, equivalent to 0.
    時間文字列として指定されます。時間が-1の場合、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>"
    PreemptEligibleTimeは、「scontrol show job ＜jobid＞」の出力に表示されます。
  • PriorityTier: Configure the partition's PriorityTier setting relative to other partitions to control the preemptive behavior when PreemptType=preempt/partition_prio.
    PriorityTier：他のパーティションと比較してパーティションのPriorityTier設定を構成し、PreemptType = preempt / partition_prioの場合のプリエンプティブな動作を制御します。
     This option is not relevant if PreemptType=preempt/qos.
    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.
    2つの異なるパーティションからの2つのジョブが同じリソースに割り当てられている場合、PriorityTier値が大きいパーティション内のジョブは、PriorityTier値が小さいパーティション内のジョブをプリエンプトします。
     If the PriorityTier values of the two partitions are equal then no preemption will occur.
    2つのパーティションのPriorityTier値が等しい場合、プリエンプションは発生しません。
     The default PriorityTier value is 1.
    デフォルトの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.
    OverSubscribe：サスペンド/レジュームメカニズムを使用したジョブプリエンプションが使用されているすべてのパーティションに対して、パーティションのOverSubscribe設定をFORCEに構成します。
     The FORCE option supports an additional parameter that controls how many jobs can oversubscribe a compute resource (FORCE[:max_share]).
    FORCEオプションは、コンピューティングリソースをオーバーサブスクライブできるジョブの数を制御する追加のパラメーターをサポートします（FORCE [：max_share]）。
     By default the max_share value is 4.
    デフォルトでは、max_shareの値は4です。
     In order to preempt jobs (and not gang schedule them), always set max_share to 1.
    ジョブをプリエンプトするために（そしてそれらをギャングスケジュールしないために）、常にmax_shareを1に設定します。
     To allow up to 2 jobs from this partition to be allocated to a common resource (and gang scheduled), set OverSubscribe=FORCE:2.
    このパーティションから最大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.
    注：PreemptType = preempt / qosは、ジョブのプリエンプションが原因で開始された場合、パーティションで1つの追加ジョブを実行できるようにします。
     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.
    たとえば、OverSubscribe = FORCE：1の構成では、通常、リソースごとに1つのジョブのみが許可されますが、QOSに基づくプリエンプションによって許可された場合、2番目のジョブを開始できます。

To enable preemption after making the configuration changes described above, restart Slurm if it is already running.
上記の構成変更を行った後にプリエンプションを有効にするには、Slurmがすでに実行されている場合は再起動します。
 Any change to the plugin settings in Slurm requires a full restart of the daemons.
Slurmでプラグイン設定を変更するには、デーモンを完全に再起動する必要があります。
 If you just change the partition PriorityTier or OverSubscribe setting, this can be updated with scontrol reconfig.
パーティションのPriorityTierまたはOverSubscribeの設定を変更するだけの場合、これはscontrolreconfigで更新できます。

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.
ジョブリクエストが、「-exclusive = user」または「--exclusive = mcs」ジョブオプションを使用して、ノード上の複数のユーザーまたはアカウントからジョブを実行するSlurmの機能を制限する場合、ジョブのプリエンプションがプリエンプトでジョブを開始するのを妨げる可能性があります。特権。
 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").
プリエンプションを使用する場合は、通常、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.
異種ジョブがプリエンプトされる場合、ジョブの最初に識別されたコンポーネントで、最高次のPreemptMode（SUSPEND（最高）、REQUEUE、CANCEL（最低））が使用され、すべてのコンポーネントのPreemptModeが設定されます。
 The GraceTime and user warning signal for each component of the heterogeneous job remain unique.
異種ジョブの各コンポーネントのGraceTimeおよびユーザー警告シグナルは一意のままです。

Preemption Design and Operation

The SelectType plugin will identify resources where a pending job can begin execution.
SelectTypeプラグインは、保留中のジョブが実行を開始できるリソースを識別します。
 When PreemptMode is configured to CANCEL, SUSPEND or REQUEUE, the select plugin will also preempt running jobs as needed to initiate the pending job.
PreemptModeがCANCEL、SUSPEND、またはREQUEUEに構成されている場合、selectプラグインは、保留中のジョブを開始するために必要に応じて実行中のジョブもプリエンプトします。
 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.
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.
selectプラグインには、開始候補である保留中のジョブごとに検討するプリエンプティブジョブの順序付きリストが渡されます。
 This list is sorted by either:
このリストは、次のいずれかでソートされています。

  1. QOS priority,
    QOSの優先順位、
  2. Partition priority and job size (to favor preempting smaller jobs), or
    パーティションの優先度とジョブサイズ（小さいジョブのプリエンプトを優先するため）、または
  3. 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.
selectプラグインは、保留中のジョブがジョブをプリエンプトせずに開始できるかどうかを判断し、プリエンプトする場合は、使用可能なリソースを使用してジョブを開始します。
 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プラグインは、優先順位リスト内の各ジョブのプリエンプションをシミュレートし、各プリエンプションの後にジョブを開始できるかどうかをテストします。
 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.
たとえば、8ノードのジョブを開始する場合、順序付けられたプリエンプション候補は2ノード、4ノード、および8ノードになります。
 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.
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.
この2段階のプロセスでは、プリエンプションの優先順位が厳密ではないジョブがプリエンプトされる場合がありますが、他の方法で必要とされるよりも少ないジョブがプリエンプトされます。
 See the SchedulerParameters configuration parameter options of preempt_reorder_count and preempt_strict_order for preemption tuning parameters.
プリエンプション調整パラメーターについては、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).
1つ以上の「シャドウ」ジョブに置き換えられた既存のジョブはすべて一時停止（プリエンプト）されます。
 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.
逆に、優先度の高い実行中のジョブが完了すると、その「シャドウ」が消え、優先度の低いパーティションのアクティブなビットマップが再構築されて、中断されたジョブを再開できるかどうかが確認されます。

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.
「select」プラグインは、ジョブのプリエンプションがいつ構成されたかを認識し、ジョブのリソースを選択するときに各パーティションの優先度を考慮に入れるように拡張されました。
 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).
各ジョブのリソースを選択するとき、セレクターは他のジョブによって使用されているリソースを回避します（共有が構成されている場合を除き、共有が構成されている場合は、負荷分散が行われます）。
 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.
ただし、ジョブのプリエンプションが有効になっている場合、selectプラグインは、それらのパーティションで共有が無効になっている場合でも、優先度の低い設定のパーティションからジョブによってすでに使用されているリソースを選択できます。

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.
PreemptMode = SUSPENDの場合、ジョブは、scontrolsuspendおよびscontrolresumeをサポートするのと同じ内部関数を使用して中断されます。
 A good way to observe the operation of the gang scheduler is by running squeue -i<time> in a terminal window.
ギャングスケジューラの動作を監視する良い方法は、ターミナルウィンドウでsqueue -i ＜time＞を実行することです。

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.
バックフィルスケジューリング中に、ジョブが1つ以上の他のジョブをプリエンプトする場合、プリエンプタージョブがそれより少ないリソースを要求した場合でも、それらのプリエンプトされたジョブのノード全体がプリエンプタージョブ用に予約されます。
 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回の埋め戻しの反復中に、要求したよりも多くのリソースをプリエンプトする可能性があります。

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.
runit.plスクリプトは、指定された秒数の間実行される単純な負荷生成アプリを起動します。
 Submit 5 single-node runit.pl jobs to run on all nodes:
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.
hipriパーティションのジョブ490は、アクティブなパーティションからジョブ485、486、および487をプリエンプトしました。
 Jobs 488 and 489 in the active partition remained running.
アクティブパーティションのジョブ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.
この例では、優先度の高いサービス品質（QOS）からパーティションに送信されたジョブが送信された場合を除いて、一度にリソース（コアなど）ごとに1つのジョブのみを実行するパーティションが1つあります。
 In that case, we want that second high priority job to be started and be gang scheduled with the other jobs on overlapping resources.
その場合、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.
「hipri」ジョブをノードn [3-5]に配置すると、ジョブ17と18の実行を継続できるのでより理想的です。
 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!
ありとあらゆる助けがここに歓迎されます！

Last modified 10 April 2020