Consumable Resources in Slurm

Slurm, using the default node allocation plug-in, allocates nodes to jobs in exclusive mode.
Slurmは、デフォルトのノード割り当てプラグインを使用して、排他モードでノードをジョブに割り当てます。
 This means that even when all the resources within a node are not utilized by a given job, another job will not have access to these resources.
これは、ノード内のすべてのリソースが特定のジョブによって使用されていない場合でも、別のジョブがこれらのリソースにアクセスできないことを意味します。
 Nodes possess resources such as processors, memory, swap, local disk, etc. and jobs consume these resources.
ノードはプロセッサ、メモリ、スワップ、ローカルディスクなどのリソースを所有しており、ジョブはこれらのリソースを消費します。
 The exclusive use default policy in Slurm can result in inefficient utilization of the cluster and of its nodes resources.
Slurmの排他的使用のデフォルトポリシーは、クラスターとそのノードリソースの非効率的な利用につながる可能性があります。
 Slurm's cons_res or consumable resource plugin is available to manage resources on a much more fine-grained basis as described below.
Slurmのcons_resまたは消耗品リソースプラグインは、以下で説明するように、はるかにきめ細かいベースでリソースを管理するために使用できます。

Using the Consumable Resource Allocation Plugin: select/cons_res

  • Consumable resources has been enhanced with several new resources --namely CPU (same as in previous version), Socket, Core, Memory as well as any combination of the logical processors with Memory:
    消費可能なリソースは、いくつかの新しいリソース、つまりCPU（以前のバージョンと同じ）、ソケット、コア、メモリ、および論理プロセッサとメモリの任意の組み合わせで強化されました。
    • CPU (CR_CPU): CPU as a consumable resource.
      CPU（CR_CPU）：消費可能なリソースとしてのCPU。
      • No notion of sockets, cores, or threads.
        ソケット、コア、またはスレッドの概念はありません。
      • On a multi-core system CPUs will be cores.
        マルチコアシステムでは、CPUがコアになります。
      • On a multi-core/hyperthread system CPUs will be threads.
        マルチコア/ハイパースレッドシステムでは、CPUはスレッドになります。
      • On a single-core systems CPUs are CPUs. ;-)
        シングルコアシステムでは、CPUはCPUです。;-)
    • Board (CR_Board): Baseboard as a consumable resource.
      ボード（CR_Board）：消耗品リソースとしてのベースボード。
    • Socket (CR_Socket): Socket as a consumable resource.
      ソケット（CR_Socket）：消耗品リソースとしてのソケット。
    • Core (CR_Core): Core as a consumable resource.
      コア（CR_Core）：消費可能なリソースとしてのコア。
    • Memory (CR_Memory) Memory only as a consumable resource.
      メモリ（CR_Memory）消費可能なリソースとしてのみメモリ。
       Note! CR_Memory assumes OverSubscribe=Yes
      注意！CR_MemoryはOverSubscribe = Yesを想定しています
    • Socket and Memory (CR_Socket_Memory): Socket and Memory as consumable resources.
      ソケットとメモリ（CR_Socket_Memory）：消耗品リソースとしてのソケットとメモリ。
    • Core and Memory (CR_Core_Memory): Core and Memory as consumable resources.
      コアとメモリ（CR_Core_Memory）：消費可能なリソースとしてのコアとメモリ。
    • CPU and Memory (CR_CPU_Memory) CPU and Memory as consumable resources.
      CPUとメモリ（CR_CPU_Memory）消費可能なリソースとしてのCPUとメモリ。
  • In the cases where Memory is the consumable resource or one of the two consumable resources the RealMemory parameter, which defines a node's amount of real memory in slurm.conf, must be set.
    メモリが消費可能なリソースまたは2つの消費可能なリソースの1つである場合、slurm.confでノードの実メモリの量を定義するRealMemoryパラメータを設定する必要があります。
  • srun's -E extension for sockets, cores, and threads are ignored within the node allocation mechanism when CR_CPU or CR_CPU_MEMORY is selected.
    CR_CPUまたはCR_CPU_MEMORYが選択されている場合、ソケット、コア、およびスレッドのsrunの-E拡張子は、ノード割り当てメカニズム内で無視されます。
     It is considered to compute the total number of tasks when -n is not specified.
    -nが指定されていない場合、タスクの総数を計算すると見なされます。
  • The job submission commands (salloc, sbatch and srun) support the options --mem=MB and --mem-per-cpu=MB permitting users to specify the maximum amount of real memory per node or per allocated required.
    ジョブ送信コマンド（salloc、sbatch、およびsrun）は、オプション--mem = MBおよび--mem-per-cpu = MBをサポートしており、ユーザーはノードごとまたは必要な割り当てごとに最大量の実メモリーを指定できます。
     This option is required in the environments where Memory is a consumable resource.
    このオプションは、メモリが消費可能なリソースである環境で必要です。
     It is important to specify enough memory since Slurm will not allow the application to use more than the requested amount of real memory.
    Slurmはアプリケーションが要求された量を超える実メモリーを使用することを許可しないため、十分なメモリーを指定することが重要です。
     The default value for --mem is 1 MB.
    --memのデフォルト値は1MBです。
     see srun man page for more details.
    詳細については、srunのmanページを参照してください。
  • All CR_s assume OverSubscribe=No or OverSubscribe=Force EXCEPT for CR_MEMORY which assumes OverSubscribe=Yes
    すべてのCR_は、OverSubscribe = NoまたはOverSubscribe = Forceを想定しています。ただし、CR_MEMORYはOverSubscribe = Yesを想定しています。
  • The consumable resource plugin is enabled via SelectType and SelectTypeParameter in the slurm.conf.
    消耗品リソースプラグインは、slurm.confのSelectTypeおよびSelectTypeParameterを介して有効になります。
    • #
# Excerpts from sample slurm.conf file
#

SelectType=select/cons_res
SelectTypeParameters=CR_Core_Memory
  • Using --overcommit or -O is allowed.
    --overcommitまたは-Oの使用は許可されています。
     When the process to logical processor pinning is enabled by using an appropriate TaskPlugin configuration parameter, the extra processes will time share the allocated resources.
    適切なTaskPlugin構成パラメーターを使用してプロセスから論理プロセッサーへのピン留めを有効にすると、追加のプロセスが割り当てられたリソースを時分割で共有します。

General Comments

  • Slurm's default select/linear plugin is using a best fit algorithm based on number of consecutive nodes.
    Slurmのデフォルトの選択/線形プラグインは、連続するノードの数に基づく最適なアルゴリズムを使用しています。
     The same node allocation approach is used in select/cons_res for consistency.
    一貫性を保つために、select / cons_resでも同じノード割り当てアプローチが使用されます。
  • The select/cons_res plugin is enabled or disabled cluster-wide.
    select / cons_resプラグインは、クラスター全体で有効または無効になります。
  • In the case where select/cons_res is not enabled, the normal Slurm behaviors are not disrupted.
    select / cons_resが有効になっていない場合、通常のSlurmの動作は中断されません。
     The only changes, users see when using the select/cons_res plugin, are that jobs can be co-scheduled on nodes when resources permit it.
    select / cons_resプラグインを使用するときにユーザーに表示される唯一の変更点は、リソースで許可されている場合に、ノードでジョブを共同スケジュールできることです。
     The rest of Slurm, such as srun and its options (except srun -s ...), etc. are not effected by this plugin.
    srunとそのオプション（srun -s ...を除く）などの残りのSlurmは、このプラグインの影響を受けません。
     Slurm is, from a user point of view, working the same way as when using the default node selection scheme.
    Slurmは、ユーザーの観点からは、デフォルトのノード選択スキームを使用する場合と同じように機能します。
  • The --exclusive srun option allows users to request nodes in exclusive mode even when consumable resources is enabled.
    --exclusive srunオプションを使用すると、消費可能なリソースが有効になっている場合でも、ユーザーは排他モードでノードを要求できます。
     see "man srun" for details.
    詳細については、「mansrun」を参照してください。
  • srun's -s or --oversubscribe is incompatible with the consumable resource environment and will therefore not be honored.
    srunの-sまたは--oversubscribeは、消費可能なリソース環境と互換性がないため、尊重されません。
     Since in this environment nodes are shared by default, --exclusive allows users to obtain dedicated nodes.
    この環境ではノードはデフォルトで共有されるため、-exclusiveを使用すると、ユーザーは専用ノードを取得できます。

Examples of CR_Memory, CR_Socket_Memory, and CR_CPU_Memory type consumable resources

# sinfo -lNe
NODELIST     NODES PARTITION  STATE  CPUS  S:C:T MEMORY
hydra[12-16]     5 allNodes*  ...       4  2:2:1   2007

Using select/cons_res plug-in with CR_Memory

Example:
# srun -N 5 -n 20 --mem=1000 sleep 100 &  <-- running
# srun -N 5 -n 20 --mem=10 sleep 100 &    <-- running
# srun -N 5 -n 10 --mem=1000 sleep 100 &  <-- queued and waiting for resources

# squeue
JOBID PARTITION   NAME   USER ST  TIME  NODES NODELIST(REASON)
 1820  allNodes  sleep sballe PD  0:00      5 (Resources)
 1818  allNodes  sleep sballe  R  0:17      5 hydra[12-16]
 1819  allNodes  sleep sballe  R  0:11      5 hydra[12-16]

Using select/cons_res plug-in with CR_Socket_Memory (2 sockets/node)

Example 1:
# srun -N 5 -n 5 --mem=1000 sleep 100 &        <-- running
# srun -n 1 -w hydra12 --mem=2000 sleep 100 &  <-- queued and waiting for resources

# squeue
JOBID PARTITION   NAME   USER ST  TIME  NODES NODELIST(REASON)
 1890  allNodes  sleep sballe PD  0:00      1 (Resources)
 1889  allNodes  sleep sballe  R  0:08      5 hydra[12-16]

Example 2:
# srun -N 5 -n 10 --mem=10 sleep 100 & <-- running
# srun -n 1 --mem=10 sleep 100 & <-- queued and waiting for resourcessqueue

# squeue
JOBID PARTITION   NAME   USER ST  TIME  NODES NODELIST(REASON)
 1831  allNodes  sleep sballe PD  0:00      1 (Resources)
 1830  allNodes  sleep sballe  R  0:07      5 hydra[12-16]

Using select/cons_res plug-in with CR_CPU_Memory (4 CPUs/node)

Example 1:
# srun -N 5 -n 5 --mem=1000 sleep 100 &  <-- running
# srun -N 5 -n 5 --mem=10 sleep 100 &    <-- running
# srun -N 5 -n 5 --mem=1000 sleep 100 &  <-- queued and waiting for resources

# squeue
JOBID PARTITION   NAME   USER ST  TIME  NODES NODELIST(REASON)
 1835  allNodes  sleep sballe PD  0:00      5 (Resources)
 1833  allNodes  sleep sballe  R  0:10      5 hydra[12-16]
 1834  allNodes  sleep sballe  R  0:07      5 hydra[12-16]

Example 2:
# srun -N 5 -n 20 --mem=10 sleep 100 & <-- running
# srun -n 1 --mem=10 sleep 100 &       <-- queued and waiting for resources

# squeue
JOBID PARTITION   NAME   USER ST  TIME  NODES NODELIST(REASON)
 1837  allNodes  sleep sballe PD  0:00      1 (Resources)
 1836  allNodes  sleep sballe  R  0:11      5 hydra[12-16]

Example of Node Allocations Using Consumable Resource Plugin

The following example illustrates the different ways four jobs are allocated across a cluster using (1) Slurm's default allocation (exclusive mode) and (2) a processor as consumable resource approach.
次の例は、（1）Slurmのデフォルトの割り当て（排他モード）と（2）消費可能なリソースアプローチとしてのプロセッサを使用して、4つのジョブがクラスター全体に割り当てられるさまざまな方法を示しています。

It is important to understand that the example listed below is a contrived example and is only given here to illustrate the use of CPU as consumable resources.
以下にリストされている例は不自然な例であり、消費可能なリソースとしてのCPUの使用を説明するためにここにのみ示されていることを理解することが重要です。
 Job 2 and Job 3 call for the node count to equal the processor count.
ジョブ2とジョブ3は、ノード数がプロセッサ数と等しくなるように要求します。
 This would typically be done because that one task per node requires all of the memory, disk space, etc.
これは通常、ノードごとに1つのタスクがすべてのメモリ、ディスクスペースなどを必要とするために行われます。
 The bottleneck would not be processor count.
ボトルネックはプロセッサ数ではありません。

Trying to execute more than one job per node will almost certainly severely impact parallel job's performance.
ノードごとに複数のジョブを実行しようとすると、ほぼ確実に並列ジョブのパフォーマンスに深刻な影響を及ぼします。
 The biggest beneficiary of CPUs as consumable resources will be serial jobs or jobs with modest parallelism, which can effectively share resources.
消費可能なリソースとしてのCPUの最大の利点は、リソースを効果的に共有できるシリアルジョブまたは適度な並列処理を備えたジョブです。
 On many systems with larger processor count, jobs typically run one fewer task than there are processors to minimize interference by the kernel and daemons.
プロセッサ数が多い多くのシステムでは、カーネルとデーモンによる干渉を最小限に抑えるために、ジョブは通常、プロセッサよりも1つ少ないタスクを実行します。

The example cluster is composed of 4 nodes (10 CPUs in total):
サンプルクラスターは、4つのノード（合計10個のCPU）で構成されています。

  • linux01 (with 2 processors),
  • linux02 (with 2 processors),
  • linux03 (with 2 processors), and
  • linux04 (with 4 processors).

The four jobs are the following:

  • [2] srun -n 4 -N 4 sleep 120 &
  • [3] srun -n 3 -N 3 sleep 120 &
  • [4] srun -n 1 sleep 120 &
  • [5] srun -n 3 sleep 120 &

The user launches them in the same order as listed above.
ユーザーは、上記と同じ順序でそれらを起動します。

Using Slurm's Default Node Allocation (Non-shared Mode)

The four jobs have been launched and 3 of the jobs are now pending, waiting to get resources allocated to them.
4つのジョブが開始され、そのうち3つのジョブは現在保留中であり、リソースが割り当てられるのを待っています。
 Only Job 2 is running since it uses one CPU on all 4 nodes.
4つのノードすべてで1つのCPUを使用するため、ジョブ2のみが実行されています。
 This means that linux01 to linux03 each have one idle CPU and linux04 has 3 idle CPUs.
つまり、linux01からlinux03にはそれぞれ1つのアイドルCPUがあり、linux04には3つのアイドルCPUがあります。

# squeue
JOBID PARTITION   NAME  USER  ST  TIME  NODES NODELIST(REASON)
    3       lsf  sleep  root  PD  0:00      3 (Resources)
    4       lsf  sleep  root  PD  0:00      1 (Resources)
    5       lsf  sleep  root  PD  0:00      1 (Resources)
    2       lsf  sleep  root   R  0:14      4 xc14n[13-16]

Once Job 2 is finished, Job 3 is scheduled and runs on linux01, linux02, and linux03.
ジョブ2が終了すると、ジョブ3がスケジュールされ、linux01、linux02、およびlinux03で実行されます。
 Job 3 is only using one CPU on each of the 3 nodes.
ジョブ3は、3つのノードのそれぞれで1つのCPUのみを使用しています。
 Job 4 can be allocated onto the remaining idle node (linux04) so Job 3 and Job 4 can run concurrently on the cluster.
ジョブ4を残りのアイドルノード（linux04）に割り当てることができるため、ジョブ3とジョブ4をクラスター上で同時に実行できます。

Job 5 has to wait for idle nodes to be able to run.
ジョブ5は、アイドル状態のノードが実行できるようになるまで待機する必要があります。

# squeue
JOBID PARTITION   NAME  USER  ST  TIME  NODES NODELIST(REASON)
    5       lsf  sleep  root  PD  0:00      1 (Resources)
    3       lsf  sleep  root   R  0:11      3 xc14n[13-15]
    4       lsf  sleep  root   R  0:11      1 xc14n16

Once Job 3 finishes, Job 5 is allocated resources and can run.
ジョブ3が終了すると、ジョブ5にリソースが割り当てられ、実行できるようになります。

The advantage of the exclusive mode scheduling policy is that the a job gets all the resources of the assigned nodes for optimal parallel performance.
排他モードスケジューリングポリシーの利点は、ジョブが割り当てられたノードのすべてのリソースを取得して、最適な並列パフォーマンスを実現できることです。
 The drawback is that jobs can tie up large amount of resources that it does not use and which cannot be shared with other jobs.
欠点は、ジョブが使用せず、他のジョブと共有できない大量のリソースを占有する可能性があることです。

Using a Processor Consumable Resource Approach

The output of squeue shows that we have 3 out of the 4 jobs allocated and running.
squeueの出力は、4つのジョブのうち3つが割り当てられて実行されていることを示しています。
 This is a 2 running job increase over the default Slurm approach.
これは、デフォルトのSlurmアプローチに比べて2回実行されるジョブの増加です。

Job 2 is running on nodes linux01 to linux04.
ジョブ2は、ノードlinux01からlinux04で実行されています。
 Job 2's allocation is the same as for Slurm's default allocation which is that it uses one CPU on each of the 4 nodes.
ジョブ2の割り当ては、Slurmのデフォルトの割り当てと同じです。つまり、4つのノードのそれぞれで1つのCPUを使用します。
 Once Job 2 is scheduled and running, nodes linux01, linux02 and linux03 still have one idle CPU each and node linux04 has 3 idle CPUs.
ジョブ2がスケジュールされて実行されると、ノードlinux01、linux02、およびlinux03にはそれぞれ1つのアイドルCPUがあり、ノードlinux04には3つのアイドルCPUがあります。
 The main difference between this approach and the exclusive mode approach described above is that idle CPUs within a node are now allowed to be assigned to other jobs.
このアプローチと上記の排他モードアプローチの主な違いは、ノード内のアイドル状態のCPUを他のジョブに割り当てることができるようになったことです。

It is important to note that assigned doesn't mean oversubscription.
割り当てられたということは、過剰なサブスクリプションを意味するものではないことに注意することが重要です。
 The consumable resource approach tracks how much of each available resource (in our case CPUs) must be dedicated to a given job.
消費可能リソースアプローチは、利用可能な各リソース（この場合はCPU）のどれだけを特定のジョブに割り当てる必要があるかを追跡します。
 This allows us to prevent per node oversubscription of resources (CPUs).
これにより、ノードごとのリソース（CPU）のオーバーサブスクリプションを防ぐことができます。

Once Job 2 is running, Job 3 is scheduled onto node linux01, linux02, and Linux03 (using one CPU on each of the nodes) and Job 4 is scheduled onto one of the remaining idle CPUs on Linux04.
ジョブ2が実行されると、ジョブ3はノードlinux01、linux02、およびLinux03にスケジュールされ（各ノードで1つのCPUを使用）、ジョブ4はLinux04の残りのアイドルCPUの1つにスケジュールされます。

Job 2, Job 3, and Job 4 are now running concurrently on the cluster.
これで、ジョブ2、ジョブ3、およびジョブ4がクラスター上で同時に実行されます。

# squeue
JOBID PARTITION   NAME  USER  ST  TIME  NODES NODELIST(REASON)
    5       lsf  sleep  root  PD  0:00      1 (Resources)
    2       lsf  sleep  root   R  0:13      4 linux[01-04]
    3       lsf  sleep  root   R  0:09      3 linux[01-03]
    4       lsf  sleep  root   R  0:05      1 linux04

# sinfo -lNe
NODELIST     NODES PARTITION       STATE CPUS MEMORY TMP_DISK WEIGHT FEATURES REASON
linux[01-03]     3      lsf*   allocated    2   2981        1      1   (null) none
linux04          1      lsf*   allocated    4   3813        1      1   (null) none

Once Job 2 finishes, Job 5, which was pending, is allocated available resources and is then running as illustrated below:
ジョブ2が終了すると、保留中のジョブ5に使用可能なリソースが割り当てられ、以下に示すように実行されます。

# squeue
JOBID PARTITION   NAME  USER  ST  TIME  NODES NODELIST(REASON)
   3       lsf   sleep  root   R  1:58      3 linux[01-03]
   4       lsf   sleep  root   R  1:54      1 linux04
   5       lsf   sleep  root   R  0:02      3 linux[01-03]
# sinfo -lNe
NODELIST     NODES PARTITION       STATE CPUS MEMORY TMP_DISK WEIGHT FEATURES REASON
linux[01-03]     3      lsf*   allocated    2   2981        1      1   (null) none
linux04          1      lsf*        idle    4   3813        1      1   (null) none

Job 3, Job 4, and Job 5 are now running concurrently on the cluster.
これで、ジョブ3、ジョブ4、およびジョブ5がクラスター上で同時に実行されます。

# squeue
JOBID PARTITION   NAME  USER  ST  TIME  NODES NODELIST(REASON)
    5       lsf  sleep  root   R  1:52      3 linux[01-03]

Job 3 and Job 4 have finished and Job 5 is still running on nodes linux[01-03].
ジョブ3とジョブ4は終了し、ジョブ5はまだノードlinux [01-03]で実行されています。

The advantage of the consumable resource scheduling policy is that the job throughput can increase dramatically.
消耗品のリソーススケジューリングポリシーの利点は、ジョブのスループットが劇的に向上することです。
 The overall job throughput/productivity of the cluster increases thereby reducing the amount of time users have to wait for their job to complete as well as increasing the overall efficiency of the use of the cluster.
クラスターの全体的なジョブスループット/生産性が向上するため、ユーザーがジョブの完了を待つ必要がある時間が短縮され、クラスターの使用の全体的な効率が向上します。
 The drawback is that users do not have the entire node dedicated to their job since they have to share nodes with other jobs if they do not use all of the resources on the nodes.
欠点は、ユーザーがノード上のすべてのリソースを使用しない場合、他のジョブとノードを共有する必要があるため、ユーザーが自分のジョブ専用のノード全体を持っていないことです。

We have added a "--exclusive" option to srun which allow users to specify that they would like their allocated nodes in exclusive mode.
srunに「--exclusive」オプションを追加しました。これにより、ユーザーは、割り当てられたノードを排他モードにすることを指定できます。
 For more information see "man srun".
詳細については、「mansrun」を参照してください。
 The reason for that is if users have mpi//threaded/openMP programs that will take advantage of all the CPUs within a node but only need one mpi process per node.
その理由は、ユーザーがノード内のすべてのCPUを利用するmpi // threaded / openMPプログラムを持っているが、ノードごとに1つのmpiプロセスしか必要としない場合です。

Last modified 21 April 2014