Gang Scheduling
Slurm supports timesliced gang scheduling in which two or more jobs are
allocated to the same resources in the same partition and these jobs are
alternately suspended to let one job at a time have dedicated access to the
resources for a configured period of time.
Slurmは、2つ以上のジョブが同じパーティション内の同じリソースに割り当てられ、これらのジョブが交互に中断されて、一度に1つのジョブが構成された期間リソースに専用アクセスできるようにするタイムスライスギャングスケジューリングをサポートします。
Slurm also supports preemptive job scheduling that allows a job in a
higher PriorityTier partition, or in a preempting QOS, to preempt other
jobs.
Slurmは、より高いPriorityTierパーティションまたはプリエンプションQOS内のジョブが他のジョブをプリエンプションできるようにするプリエンプティブジョブスケジューリングもサポートします。
Preemption is related to Gang scheduling
because SUSPEND is one of the PreemptionModes, and it uses the Gang
scheduler to resume suspended jobs.
SUSPENDはPreemptionModeの1つであり、Gangスケジューラーを使用して中断されたジョブを再開するため、プリエンプションはギャングスケジューリングに関連しています。
A workload manager that supports timeslicing can improve responsiveness
and utilization by allowing more jobs to begin running sooner.
タイムスライシングをサポートするワークロードマネージャーは、より多くのジョブをより早く実行できるようにすることで、応答性と使用率を向上させることができます。
Shorter-running jobs no longer have to wait in a queue behind longer-running
jobs.
実行時間の短いジョブは、実行時間の長いジョブの後ろのキューで待機する必要がなくなりました。
Instead they can be run "in parallel" with the longer-running jobs, which will
allow them to start and finish quicker.
代わりに、実行時間の長いジョブと「並行して」実行できるため、開始と終了が速くなります。
Throughput is also improved because overcommitting the resources provides
opportunities for "local backfilling" to occur (see example below).
リソースをオーバーコミットすると、「ローカルバックフィル」が発生する機会が提供されるため、スループットも向上します（以下の例を参照）。
The gang scheduling logic works on each partition independently.
ギャングスケジューリングロジックは、各パーティションで個別に機能します。
If a new job has been allocated to resources in a partition that have already
been allocated to an existing job, then the plugin will suspend the new job
until the configured SchedulerTimeslice interval has elapsed.
既存のジョブにすでに割り当てられているパーティション内のリソースに新しいジョブが割り当てられている場合、プラグインは、構成されたSchedulerTimeslice間隔が経過するまで新しいジョブを一時停止します。
Then it will suspend the running job and let the new job make use of the
resources for a SchedulerTimeslice interval.
次に、実行中のジョブを一時停止し、新しいジョブがSchedulerTimeslice間隔でリソースを使用できるようにします。
This will continue until one of the jobs terminates.
これは、ジョブの1つが終了するまで続きます。
Configuration
There are several important configuration parameters relating to
gang scheduling:
ギャングスケジューリングに関連するいくつかの重要な構成パラメーターがあります。
-
SelectType: The Slurm gang scheduler 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 will be getting overallocated
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）。
-
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 that in order to gang schedule jobs, all jobs must be able to fit into memory at the same time.
ジョブをギャングスケジュールするには、すべてのジョブが同時にメモリに収まる必要があることに注意してください。
-
JobAcctGatherType and JobAcctGatherFrequency:
If you wish to enforce memory limits, either that task/cgroup must be
configured to limit each job's memory use or accounting must be enabled
using the JobAcctGatherType and JobAcctGatherFrequency
parameters.
JobAcctGatherTypeおよびJobAcctGatherFrequency：メモリ制限を適用する場合は、各ジョブのメモリ使用を制限するようにタスク/ cgroupを構成するか、JobAcctGatherTypeおよびJobAcctGatherFrequencyパラメーターを使用してアカウンティングを有効にする必要があります。
If 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.
アカウンティングが有効になっていて、ジョブが構成されたメモリ制限を超えた場合、同じリソースを共有する他のジョブに悪影響を与えることを防ぐために、ジョブはキャンセルされます。
-
PreemptMode: set the GANG option.
PreemptMode：GANGオプションを設定します。
See the slurm.conf manpage for other options that may be specified to enable job preemption in addition to GANG.
GANGに加えてジョブのプリエンプションを有効にするために指定できるその他のオプションについては、slurm.confのマンページを参照してください。
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 the Gang scheduler to resume the suspended job(s).
一方、PreemptType = preempt / partition_prioを使用して、優先度の高いパーティションからのジョブを優先度の低いパーティションからのジョブを一時停止できるようにする場合は、パーティションをオーバーラップさせる必要があります。PreemptMode= SUSPEND、GANGを使用して、ギャングスケジューラを使用して再開します。中断されたジョブ。
In any case, time-slicing won't happen between jobs on different partitions.
いずれの場合も、異なるパーティション上のジョブ間でタイムスライスは発生しません。
-
SchedulerTimeSlice: The default timeslice interval is 30 seconds.
SchedulerTimeSlice：デフォルトのタイムスライス間隔は30秒です。
To change this duration, set SchedulerTimeSlice to the desired interval (in seconds) in slurm.conf.
この期間を変更するには、slurm.confでSchedulerTimeSliceを目的の間隔（秒単位）に設定します。
For example, to set the timeslice interval to one minute, set SchedulerTimeSlice=60.
たとえば、タイムスライス間隔を1分に設定するには、SchedulerTimeSlice = 60を設定します。
Short values can increase the overhead of gang scheduling.
値が短いと、ギャングスケジューリングのオーバーヘッドが増える可能性があります。
-
OverSubscribe: Configure the partition's OverSubscribe setting to
FORCE for all partitions in which timeslicing is to take place.
OverSubscribe：タイムスライスが行われるすべてのパーティションに対して、パーティションのOverSubscribe設定をFORCEに構成します。
The FORCE option supports an additional parameter that controls how many jobs can share a compute resource (FORCE[:max_share]).
FORCEオプションは、計算リソースを共有できるジョブの数を制御する追加のパラメーター（FORCE [：max_share]）をサポートします。
By default the max_share value is 4.
デフォルトでは、max_shareの値は4です。
To allow up to 6 jobs from this partition to be allocated to a common resource, set OverSubscribe=FORCE:6.
このパーティションから最大6つのジョブを共通のリソースに割り当てることができるようにするには、OverSubscribe = FORCE：6を設定します。
To only let 2 jobs timeslice on the same resources, set OverSubscribe=FORCE:2.
同じリソースで2つのジョブのみをタイムスライスするには、OverSubscribe = FORCE：2を設定します。
In order to enable gang scheduling 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 OverSubscribe setting, this can be updated with
scontrol reconfig.
パーティションのOverSubscribe設定を変更するだけの場合は、scontrolreconfigで更新できます。
Timeslicer Design and Operation
When enabled, the gang scheduler 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 time a new
job is allocated to resources in a partition, the gang scheduler
compares these newly allocated resources with the resources already maintained
in the "active bitmap".
パーティション内のリソースに新しいジョブが割り当てられるたびに、ギャングスケジューラは、これらの新しく割り当てられたリソースを、「アクティブなビットマップ」ですでに維持されているリソースと比較します。
If these two sets of resources are disjoint then the new job is added to the "active bitmap".
これらの2つのリソースのセットが互いに素である場合、新しいジョブが「アクティブなビットマップ」に追加されます。
If these two sets of resources overlap then
the new job is suspended.
これらの2つのリソースのセットが重複している場合、新しいジョブは一時停止されます。
All jobs are tracked in a per-partition job queue
within the gang scheduler logic.
すべてのジョブは、ギャングスケジューラロジック内のパーティションごとのジョブキューで追跡されます。
A separate timeslicer thread is spawned by the gang scheduler
on startup.
別のタイムスライサースレッドは、起動時にギャングスケジューラによって生成されます。
This thread sleeps for the configured SchedulerTimeSlice
interval.
このスレッドは、構成されたSchedulerTimeSlice間隔の間スリープします。
When it wakes up, it checks each partition for suspended jobs.
ウェイクアップすると、中断されたジョブがないか各パーティションをチェックします。
If
suspended jobs are found then the timeslicer thread moves all running
jobs to the end of the job queue.
中断されたジョブが見つかった場合、タイムスライサースレッドは実行中のすべてのジョブをジョブキューの最後に移動します。
It then reconstructs the "active bitmap" for
this partition beginning with the suspended job that has waited the longest to
run (this will be the first suspended job in the run queue).
次に、このパーティションの「アクティブなビットマップ」を再構築します。これは、実行を最も長く待機した中断されたジョブから始まります（これは、実行キュー内の最初の中断されたジョブになります）。
Each following job
is then compared with the new "active bitmap", and if the job can be run
concurrently with the other "active" jobs then the job is added.
次に、後続の各ジョブが新しい「アクティブなビットマップ」と比較され、ジョブを他の「アクティブな」ジョブと同時に実行できる場合は、ジョブが追加されます。
Once this is
complete then the timeslicer thread suspends any currently running jobs
that are no longer part of the "active bitmap", and resumes jobs that are new
to the "active bitmap".
これが完了すると、タイムスライサースレッドは、「アクティブビットマップ」の一部ではなくなった現在実行中のジョブを一時停止し、「アクティブビットマップ」に新しいジョブを再開します。
This timeslicer thread algorithm for rotating jobs is designed to prevent jobs from starving (remaining in the suspended state indefinitely) and
to be as fair as possible in the distribution of runtime while still keeping
all of the resources as busy as possible.
ジョブをローテーションするためのこのタイムスライサースレッドアルゴリズムは、ジョブが不足するのを防ぎ（無期限に一時停止状態のままになる）、すべてのリソースを可能な限りビジーに保ちながら、ランタイムの分散を可能な限り公平にするように設計されています。
The gang scheduler suspends jobs via the same internal functions that
support scontrol suspend and scontrol resume.
ギャングスケジューラは、scontrolsuspendおよびscontrolresumeをサポートするのと同じ内部関数を介してジョブを一時停止します。
A good way to observe the operation of the timeslicer is by running
squeue -i<time> in a terminal window where time is set
equal to SchedulerTimeSlice.
タイムスライサーの動作を監視する良い方法は、時間がSchedulerTimeSliceに等しく設定されているターミナルウィンドウでsqueue -i ＜time＞を実行することです。
A Simple Example
The following example is configured with select/linear and OverSubscribe=FORCE.
次の例は、select / linearおよびOverSubscribe = FORCEで構成されています。
This example takes place on a small cluster of 5 nodes:
この例は、5ノードの小さなクラスターで行われます。
[user@n16 load]$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST active* up infinite 5 idle n[12-16]
Here are the Scheduler settings (excerpt of output):
スケジューラの設定（出力の抜粋）は次のとおりです。
[user@n16 load]$ scontrol show config ... PreemptMode = GANG ... SchedulerTimeSlice = 30 SchedulerType = sched/builtin ...
The myload script launches a simple load-generating app that runs
for the given number of seconds.
myloadスクリプトは、指定された秒数の間実行される単純な負荷生成アプリを起動します。
Submit myload to run on all nodes:
myloadを送信して、すべてのノードで実行します。
[user@n16 load]$ sbatch -N5 ./myload 300
sbatch: Submitted batch job 3
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
3 active myload user 0:05 5 n[12-16]
Submit it again and watch the gang scheduler suspend it:
もう一度送信して、ギャングスケジューラが一時停止するのを確認してください。
[user@n16 load]$ sbatch -N5 ./myload 300
sbatch: Submitted batch job 4
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
3 active myload user R 0:13 5 n[12-16]
4 active myload user S 0:00 5 n[12-16]
After 30 seconds the gang scheduler swaps jobs, and now job 4 is the
active one:
30秒後、ギャングスケジューラはジョブを交換し、ジョブ4がアクティブになります。
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
4 active myload user R 0:08 5 n[12-16]
3 active myload user S 0:41 5 n[12-16]
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
4 active myload user R 0:21 5 n[12-16]
3 active myload user S 0:41 5 n[12-16]
After another 30 seconds the gang scheduler sets job 3 running again:
さらに30秒後、ギャングスケジューラはジョブ3を再度実行するように設定します。
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
3 active myload user R 0:50 5 n[12-16]
4 active myload user S 0:30 5 n[12-16]
A possible side effect of timeslicing: Note that jobs that are
immediately suspended may cause their srun commands to produce the
following output:
タイムスライスの考えられる副作用：すぐに中断されたジョブにより、srunコマンドが次の出力を生成する可能性があることに注意してください。
[user@n16 load]$ cat slurm-4.out srun: Job step creation temporarily disabled, retrying srun: Job step creation still disabled, retrying srun: Job step creation still disabled, retrying srun: Job step creation still disabled, retrying srun: Job step created
This occurs because srun is attempting to launch a jobstep in an
allocation that has been suspended.
これは、srunが一時停止された割り当てでジョブステップを起動しようとしているために発生します。
The srun process will continue in a
retry loop to launch the jobstep until the allocation has been resumed and the
jobstep can be launched.
srunプロセスは、割り当てが再開されてジョブステップを起動できるようになるまで、再試行ループで続行してジョブステップを起動します。
When the gang scheduler is enabled, this type of output in the user
jobs should be considered benign.
ギャングスケジューラが有効になっている場合、ユーザージョブでのこのタイプの出力は無害であると見なす必要があります。
More examples
The following example shows how the timeslicer algorithm keeps the resources
busy.
次の例は、タイムスライサーアルゴリズムがリソースをビジー状態に保つ方法を示しています。
Job 10 runs continually, while jobs 9 and 11 are timesliced:
ジョブ10は継続的に実行されますが、ジョブ9と11はタイムスライスされます。
[user@n16 load]$ sbatch -N3 ./myload 300
sbatch: Submitted batch job 9
[user@n16 load]$ sbatch -N2 ./myload 300
sbatch: Submitted batch job 10
[user@n16 load]$ sbatch -N3 ./myload 300
sbatch: Submitted batch job 11
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
9 active myload user R 0:11 3 n[12-14]
10 active myload user R 0:08 2 n[15-16]
11 active myload user S 0:00 3 n[12-14]
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
10 active myload user R 0:50 2 n[15-16]
11 active myload user R 0:12 3 n[12-14]
9 active myload user S 0:41 3 n[12-14]
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
10 active myload user R 1:04 2 n[15-16]
11 active myload user R 0:26 3 n[12-14]
9 active myload user S 0:41 3 n[12-14]
[user@n16 load]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST
9 active myload user R 0:46 3 n[12-14]
10 active myload user R 1:13 2 n[15-16]
11 active myload user S 0:30 3 n[12-14]
The next example displays "local backfilling":
次の例は、「ローカル埋め戻し」を表示します。
[user@n16 load]$ sbatch -N3 ./myload 300 sbatch: Submitted batch job 12 [user@n16 load]$ sbatch -N5 ./myload 300 sbatch: Submitted batch job 13 [user@n16 load]$ sbatch -N2 ./myload 300 sbatch: Submitted batch job 14 [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 12 active myload user R 0:14 3 n[12-14] 14 active myload user R 0:06 2 n[15-16] 13 active myload user S 0:00 5 n[12-16]
Without timeslicing and without the backfill scheduler enabled, job 14 has to
wait for job 13 to finish.
タイムスライスがなく、バックフィルスケジューラが有効になっていない場合、ジョブ14はジョブ13が終了するのを待つ必要があります。
This is called "local" backfilling because the backfilling only occurs with
jobs close enough in the queue to get allocated by the scheduler as part of
oversubscribing the resources.
これは「ローカル」バックフィルと呼ばれます。これは、バックフィルがキュー内で十分に近く、リソースのオーバーサブスクライブの一部としてスケジューラーによって割り当てられるジョブでのみ発生するためです。
Recall that the number of jobs that can
overcommit a resource is controlled by the OverSubscribe=FORCE:max_share value,
so this value effectively controls the scope of "local backfilling".
リソースをオーバーコミットできるジョブの数はOverSubscribe = FORCE：max_share値によって制御されるため、この値は「ローカルバックフィル」のスコープを効果的に制御することを思い出してください。
Normal backfill algorithms check all jobs in the wait queue.
通常の埋め戻しアルゴリズムは、待機キュー内のすべてのジョブをチェックします。
Consumable Resource Examples
The following two examples illustrate the primary difference between
CR_CPU and CR_Core when consumable resource selection is enabled
(select/cons_res).
次の2つの例は、消耗品リソースの選択が有効になっている場合のCR_CPUとCR_Coreの主な違いを示しています（select / cons_res）。
When CR_CPU (or CR_CPU_Memory) is configured then the selector
treats the CPUs as simple, interchangeable computing resources
unless task affinity is enabled.
CR_CPU（またはCR_CPU_Memory）が構成されている場合、タスクアフィニティが有効になっていない限り、セレクタはCPUを単純で交換可能なコンピューティングリソースとして扱います。
However when task affinity is enabled
with CR_CPU or CR_Core (or CR_Core_Memory) is enabled, the
selector treats the CPUs as individual resources that are specifically
allocated to jobs.
ただし、タスクアフィニティがCR_CPUで有効になっている場合、またはCR_Core（またはCR_Core_Memory）が有効になっている場合、セレクタはCPUをジョブに特別に割り当てられた個別のリソースとして扱います。
This subtle difference is highlighted when timeslicing is enabled.
この微妙な違いは、タイムスライスが有効になっている場合に強調表示されます。
In both examples 6 jobs are submitted.
どちらの例でも、6つのジョブが送信されます。
Each job requests 2 CPUs per node, and
all of the nodes contain two quad-core processors.
各ジョブはノードごとに2つのCPUを要求し、すべてのノードには2つのクアッドコアプロセッサが含まれています。
The timeslicer will
initially let the first 4 jobs run and suspend the last 2 jobs.
タイムスライサーは、最初に最初の4つのジョブを実行させ、最後の2つのジョブを一時停止します。
The manner in which these jobs are timesliced depends upon the configured
SelectTypeParameter.
これらのジョブがタイムスライスされる方法は、構成されたSelectTypeParameterによって異なります。
In the first example CR_Core_Memory is configured.
最初の例では、CR_Core_Memoryが構成されています。
Note that jobs 46
and 47 don't ever get suspended.
ジョブ46と47が中断されることはないことに注意してください。
This is because they are not sharing
their cores with any other job.
これは、コアを他のジョブと共有していないためです。
Jobs 48 and 49 were allocated to the same cores as jobs 44 and 45.
ジョブ48と49は、ジョブ44と45と同じコアに割り当てられました。
The timeslicer recognizes this and timeslices only those jobs:
タイムスライサーはこれを認識し、それらのジョブのみをタイムスライスします。
[user@n16 load]$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST active* up infinite 5 idle n[12-16] [user@n16 load]$ scontrol show config | grep Select SelectType = select/cons_res SelectTypeParameters = CR_CORE_MEMORY [user@n16 load]$ sinfo -o "%20N %5D %5c %5z" NODELIST NODES CPUS S:C:T n[12-16] 5 8 2:4:1 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 44 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 45 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 46 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 47 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 48 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 49 [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 44 active myload user R 0:09 5 n[12-16] 45 active myload user R 0:08 5 n[12-16] 46 active myload user R 0:08 5 n[12-16] 47 active myload user R 0:07 5 n[12-16] 48 active myload user S 0:00 5 n[12-16] 49 active myload user S 0:00 5 n[12-16] [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 46 active myload user R 0:49 5 n[12-16] 47 active myload user R 0:48 5 n[12-16] 48 active myload user R 0:06 5 n[12-16] 49 active myload user R 0:06 5 n[12-16] 44 active myload user S 0:44 5 n[12-16] 45 active myload user S 0:43 5 n[12-16] [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 44 active myload user R 1:23 5 n[12-16] 45 active myload user R 1:22 5 n[12-16] 46 active myload user R 2:22 5 n[12-16] 47 active myload user R 2:21 5 n[12-16] 48 active myload user S 1:00 5 n[12-16] 49 active myload user S 1:00 5 n[12-16]
Note the runtime of all 6 jobs in the output of the last squeue command.
最後のsqueueコマンドの出力にある6つのジョブすべての実行時間に注意してください。
Jobs 46 and 47 have been running continuously, while jobs 44 and 45 are
splitting their runtime with jobs 48 and 49.
ジョブ46と47は継続的に実行されていますが、ジョブ44と45はランタイムをジョブ48と49に分割しています。
The next example has CR_CPU_Memory configured and the same 6 jobs are
submitted.
次の例では、CR_CPU_Memoryが構成されており、同じ6つのジョブが送信されます。
Here the selector and the timeslicer treat the CPUs as countable
resources which results in all 6 jobs sharing time on the CPUs:
ここで、セレクターとタイムスライサーはCPUをカウント可能なリソースとして扱い、その結果、6つのジョブすべてがCPUで時間を共有します。
[user@n16 load]$ sinfo PARTITION AVAIL TIMELIMIT NODES STATE NODELIST active* up infinite 5 idle n[12-16] [user@n16 load]$ scontrol show config | grep Select SelectType = select/cons_res SelectTypeParameters = CR_CPU_MEMORY [user@n16 load]$ sinfo -o "%20N %5D %5c %5z" NODELIST NODES CPUS S:C:T n[12-16] 5 8 2:4:1 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 51 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 52 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 53 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 54 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 55 [user@n16 load]$ sbatch -n10 -N5 ./myload 300 sbatch: Submitted batch job 56 [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 51 active myload user R 0:11 5 n[12-16] 52 active myload user R 0:11 5 n[12-16] 53 active myload user R 0:10 5 n[12-16] 54 active myload user R 0:09 5 n[12-16] 55 active myload user S 0:00 5 n[12-16] 56 active myload user S 0:00 5 n[12-16] [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 51 active myload user R 1:09 5 n[12-16] 52 active myload user R 1:09 5 n[12-16] 55 active myload user R 0:23 5 n[12-16] 56 active myload user R 0:23 5 n[12-16] 53 active myload user S 0:45 5 n[12-16] 54 active myload user S 0:44 5 n[12-16] [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 53 active myload user R 0:55 5 n[12-16] 54 active myload user R 0:54 5 n[12-16] 55 active myload user R 0:40 5 n[12-16] 56 active myload user R 0:40 5 n[12-16] 51 active myload user S 1:16 5 n[12-16] 52 active myload user S 1:16 5 n[12-16] [user@n16 load]$ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST 51 active myload user R 3:18 5 n[12-16] 52 active myload user R 3:18 5 n[12-16] 53 active myload user R 3:17 5 n[12-16] 54 active myload user R 3:16 5 n[12-16] 55 active myload user S 3:00 5 n[12-16] 56 active myload user S 3:00 5 n[12-16]
Note that the runtime of all 6 jobs is roughly equal.
6つのジョブすべての実行時間はほぼ等しいことに注意してください。
Jobs 51-54 ran first so
they're slightly ahead, but so far all jobs have run for at least 3 minutes.
ジョブ51〜54が最初に実行されたため、わずかに進んでいますが、これまでのところ、すべてのジョブは少なくとも3分間実行されています。
At the core level this means that Slurm relies on the Linux kernel to move
jobs around on the cores to maximize performance.
コアレベルでは、これは、SlurmがLinuxカーネルに依存してコア上でジョブを移動し、パフォーマンスを最大化することを意味します。
This is different than when CR_Core_Memory was configured and the jobs
would effectively remain "pinned" to their specific cores for the duration of
the job.
これは、CR_Core_Memoryが構成されたときとは異なり、ジョブは、ジョブの期間中、特定のコアに効果的に「固定」されたままになります。
Note that CR_Core_Memory supports CPU binding, while
CR_CPU_Memory does not.
CR_Core_MemoryはCPUバインディングをサポートしていますが、CR_CPU_Memoryはサポートしていないことに注意してください。
Note that manually suspending a job (i.e. "scontrol suspend ...") releases
its CPUs for allocation to other jobs.
ジョブを手動で一時停止する（つまり、「scontrol suspend ...」）と、他のジョブに割り当てるためにCPUが解放されることに注意してください。
Resuming a previously suspended job may result in multiple jobs being
allocated the same CPUs, which could trigger gang scheduling of jobs.
以前に中断されたジョブを再開すると、複数のジョブに同じCPUが割り当てられ、ジョブのギャングスケジューリングがトリガーされる可能性があります。
Use of the scancel command to send SIGSTOP and SIGCONT signals would stop a
job without releasing its CPUs for allocation to other jobs and would be a
preferable mechanism in many cases.
scancelコマンドを使用してSIGSTOPおよびSIGCONTシグナルを送信すると、他のジョブに割り当てるためにCPUを解放せずにジョブが停止し、多くの場合、推奨されるメカニズムになります。
Last modified 10 March 2020