Large Cluster Administration Guide
This document contains Slurm administrator information specifically
for clusters containing 1,024 nodes or more.
Large systems currently managed by Slurm include
Tianhe-2 (at the National University of Defense Technology in China with
16,000 compute nodes and 3.1 million cores) and
Sequoia (IBM Bluegene/Q at Lawrence Livermore National Laboratory with
98,304 compute nodes and 1.6 million cores).
Slurm operation on systems orders of magnitude larger has been validated
using emulation.
Getting optimal performance at that scale does require some tuning and
this document should help get you off to a good start.
A working knowledge of Slurm should be considered a prerequisite
for this material.
このドキュメントには、特に1,024ノード以上を含むクラスター向けのSlurm管理者情報が含まれています。現在Slurmが管理している大規模なシステムには、Tianhe-2（16,000の計算ノードと310万のコアを持つ中国の国立防衛技術大学）とSequoia（98,304の計算ノードと160万のコアを持つIBM Bluegene / Q at Lawrence Livermore National Laboratory）が含まれます。 。桁違いのシステムでのスラム操作は、エミュレーションを使用して検証されています。その規模で最適なパフォーマンスを得るには、多少の調整が必要です。このドキュメントは、良いスタートを切るのに役立つはずです。Slurmの実用的な知識は、この資料の前提条件と見なされます。
Performance
Times below are for execution of an MPI program printing "Hello world" and
exiting and includes the time for processing output. Your performance may
vary due to differences in hardware, software, and configuration.
以下の時間は、 "Hello world"を出力して終了するMPIプログラムの実行時間であり、出力を処理する時間を含みます。ハードウェア、ソフトウェア、構成の違いにより、パフォーマンスが異なる場合があります。
- 1,966,080 tasks on 122,880 compute nodes of a BlueGene/Q: 322 seconds
BlueGene / Qの122,880計算ノードでの1,966,080タスク：322秒 - 30,000 tasks on 15,000 compute nodes of a Linux cluster: 30 seconds
Linuxクラスターの15,000コンピューティングノードで30,000タスク：30秒
System Configuration
Three system configuration parameters must be set to support a large number
of open files and TCP connections with large bursts of messages. Changes can
be made using the /etc/rc.d/rc.local or /etc/sysctl.conf
script to preserve changes after reboot. In either case, you can write values
directly into these files
(e.g. "echo 32832 > /proc/sys/fs/file-max").
多数のオープンファイルと大量のメッセージバーストを伴うTCP接続をサポートするには、3つのシステム構成パラメーターを設定する必要があります。/etc/rc.d/rc.localまたは/etc/sysctl.confスクリプトを使用して変更を加え、再起動後に変更を保存できます。どちらの場合も、これらのファイルに直接値を書き込むことができます（例： "echo 32832> / proc / sys / fs / file-max"）。
- /proc/sys/fs/file-max:
The maximum number of concurrently open files.
We recommend a limit of at least 32,832.
/ proc / sys / fs / file-max：同時に開くファイルの最大数。少なくとも32,832の制限をお勧めします。 - /proc/sys/net/ipv4/tcp_max_syn_backlog:
Maximum number of remembered connection requests, which still have not
received an acknowledgment from the connecting client.
The default value is 1024 for systems with more than 128Mb of memory, and 128
for low memory machines. If server suffers of overload, try to increase this
number.
/ proc / sys / net / ipv4 / tcp_max_syn_backlog：記憶されている接続要求の最大数。これは、接続しているクライアントから確認応答をまだ受け取っていません。デフォルト値は、128Mbを超えるメモリを搭載したシステムでは1024、低メモリマシンでは128です。サーバーが過負荷になっている場合は、この数を増やしてみてください。 - /proc/sys/net/core/somaxconn:
Limit of socket listen() backlog, known in userspace as SOMAXCONN. Defaults to
128. The value should be raised substantially to support bursts of request.
For example, to support a burst of 1024 requests, set somaxconn to 1024.
/ proc / sys / net / core / somaxconn：ソケットのlisten（）バックログの制限。ユーザースペースではSOMAXCONNとして知られています。デフォルトは128です。リクエストのバーストをサポートするには、この値を大幅に増やす必要があります。たとえば、1024リクエストのバーストをサポートするには、somaxconnを1024に設定します。
The transmit queue length (txqueuelen) may also need to be modified
using the ifconfig command. A value of 4096 has been found to work well for one
site with a very large cluster
(e.g. "ifconfig
送信キューの長さ（txqueuelen）も、ifconfigコマンドを使用して変更する必要がある場合があります。非常に大きなクラスターがある1つのサイトでは、4096の値が適切に機能することがわかっています（たとえば、「ifconfig txqueuelen 4096」）。
Thread/Process Limit
There is a newly introduced limit in SLES 12 SP2 (used on Cray systems
with CLE 6.0UP04, to be released mid-2017).
The version of systemd shipped with SLES 12 SP2 contains support for the
PIDs cgroup controller.
Under the new systemd version, each init script or systemd service is limited
to 512 threads/processes by default.
This could cause issues for the slurmctld and slurmd daemons on large clusters
or systems with a high job throughput rate.
To increase the limit beyond the default:
SLES 12 SP2に新しく導入された制限があります（2017年半ばにリリース予定のCLE 6.0UP04を搭載したCrayシステムで使用されます）。SLES 12 SP2に付属するsystemdのバージョンには、PID cgroupコントローラーのサポートが含まれています。新しいsystemdバージョンでは、各initスクリプトまたはsystemdサービスは、デフォルトで512スレッド/プロセスに制限されています。これにより、ジョブのスループット率が高い大規模なクラスターまたはシステムで、slurmctldおよびslurmdデーモンに問題が発生する可能性があります。デフォルトを超えて制限を増やすには：
- If using a systemd service file: Add TasksMax=N to the [Service]
section. N can be a specific number, or special value infinity.
systemdサービスファイルを使用している場合：[Service]セクションにTasksMax = Nを追加します。Nは特定の数値、または特別な値の無限大です。 - If using an init script: Create the file
/etc/systemd/system/<init script name>.service.d/override.conf
with these contents:
initスクリプトを使用する場合：ファイル/ etc / systemd / system /を作成します.service.d / override.confwithこれらのコンテンツ：
[Service] TasksMax=N
Note: Earlier versions of systemd that don't support the PIDs cgroup
controller simply ignore the TasksMax setting.
注：PID cgroupコントローラーをサポートしない以前のバージョンのsystemdは、TasksMax設定を無視するだけです。
User Limits
The ulimit values in effect for the slurmctld daemon should
be set quite high for memory size, open file count and stack size.
slurmctldデーモンに有効なulimit値は、メモリー・サイズ、オープン・ファイル数、およびスタック・サイズに対して非常に高く設定する必要があります。
Node Selection Plugin (SelectType)
While allocating individual processors within a node is great
for smaller clusters, the overhead of keeping track of the individual
processors and memory within each node adds significant overhead.
For best scalability, allocate whole nodes using select/linear
and avoid select/cons_res.
ノード内に個々のプロセッサを割り当てることは、小規模なクラスタには最適ですが、各ノード内の個々のプロセッサとメモリを追跡するオーバーヘッドは、かなりのオーバーヘッドを追加します。最高のスケーラビリティを得るには、select / linearを使用してノード全体を割り当て、select / cons_resを回避します。
Job Accounting Gather Plugin (JobAcctGatherType)
Job accounting relies upon the slurmstepd daemon on each compute
node periodically sampling data.
This data collection will take compute cycles away from the application
inducing what is known as system noise.
For large parallel applications, this system noise can detract from
application scalability.
For optimal application performance, disabling job accounting
is best (jobacct_gather/none).
Consider use of job completion records (JobCompType) for accounting
purposes as this entails far less overhead.
If job accounting is required, configure the sampling interval
to a relatively large size (e.g. JobAcctGatherFrequency=300).
Some experimentation may be required to deal with collisions
on data transmission.
ジョブアカウンティングは、各計算ノードのslurmstepdデーモンを使用して、定期的にデータをサンプリングします。このデータ収集は、アプリケーションから計算サイクルを取り除き、システムノイズと呼ばれるものを引き起こします。大規模な並列アプリケーションの場合、このシステムノイズはアプリケーションのスケーラビリティを損なう可能性があります。アプリケーションのパフォーマンスを最適化するには、ジョブアカウンティングを無効にするのが最適です（jobacct_gather / none）。オーバーヘッドがはるかに少ないため、アカウンティングの目的でジョブ完了レコード（JobCompType）を使用することを検討してください。ジョブアカウンティングが必要な場合は、サンプリング間隔を比較的大きなサイズに構成します（例：JobAcctGatherFrequency = 300）。データ送信の衝突に対処するには、いくつかの実験が必要になる場合があります。
Node Configuration
While Slurm can track the amount of memory and disk space actually found
on each compute node and use it for scheduling purposes, this entails
extra overhead.
Optimize performance by specifying the expected configuration using
the available parameters (RealMemory, CPUs, and
TmpDisk).
If the node is found to contain less resources than configured,
it will be marked DOWN and not used.
While Slurm can easily handle a heterogeneous cluster, configuring
the nodes using the minimal number of lines in slurm.conf
will both make for easier administration and better performance.
Slurmは、各計算ノードで実際に検出されたメモリとディスク容量を追跡し、それをスケジューリングの目的で使用できますが、これには追加のオーバーヘッドが伴います。使用可能なパラメーター（RealMemory、CPU、およびTmpDisk）を使用して予想される構成を指定することにより、パフォーマンスを最適化します。ノードに含まれているリソースが構成されているよりも少ないことが判明した場合、そのノードはDOWNとマークされ、使用されません。Slurmは異種のクラスターを簡単に処理できますが、slurm.confで最小限の行数を使用してノードを構成すると、管理が容易になり、パフォーマンスが向上します。
Timers
The EioTimeout configuration parameter controls how long the srun
command will wait for the slurmstepd to close the TCP/IP connection used to
relay data between the user application and srun when the user application
terminates. The default value is 60 seconds. Larger systems and/or slower
networks may need a higher value.
EioTimeout構成パラメーターは、srunコマンドがslurmstepdがユーザーアプリケーションの終了時にユーザーアプリケーションとsrunの間でデータを中継するために使用されるTCP / IP接続を閉じるまで待機する時間を制御します。デフォルト値は60秒です。大規模なシステムや低速のネットワークでは、より高い値が必要になる場合があります。
If a high throughput of jobs is anticipated (i.e. large numbers of jobs
with brief execution times) then configure MinJobAge to the smallest
interval practical for your environment. MinJobAge specifies the
minimum number of seconds that a terminated job will be retained by Slurm's
control daemon before purging. After this time, information about terminated
jobs will only be available through accounting records.
ジョブの高いスループットが予想される場合（つまり、実行時間が短い多数のジョブ）、MinJobAgeを環境に最適な最小間隔に構成します。MinJobAgeは、パージされる前に終了したジョブがSlurmの制御デーモンによって保持される最小秒数を指定します。この時間が経過すると、終了したジョブに関する情報は、アカウンティングレコードを通じてのみ利用可能になります。
The configuration parameter SlurmdTimeout determines the interval
at which slurmctld routinely communicates with slurmd.
Communications occur at half the SlurmdTimeout value.
The purpose of this is to determine when a compute node fails
and thus should not be allocated work.
Longer intervals decrease system noise on compute nodes (we do
synchronize these requests across the cluster, but there will
be some impact upon applications).
For really large clusters, SlurmdTimeout values of
120 seconds or more are reasonable.
構成パラメーターSlurmdTimeoutは、slurmctldがslurmdと定期的に通信する間隔を決定します。通信はSlurmdTimeout値の半分で発生します。これの目的は、計算ノードに障害が発生したときに作業を割り当てる必要がないことを確認することです。間隔を長くすると、計算ノードのシステムノイズが減少します（これらの要求はクラスター全体で同期されますが、アプリケーションに影響があります）。非常に大規模なクラスターでは、120秒以上のSlurmdTimeout値が妥当です。
If MPICH-2 is used, the srun command will manage the key-pairs
used to bootstrap the application.
Depending upon the processor speed and architecture, the communication
of key-pair information may require extra time.
This can be done by setting an environment variable PMI_TIME before
executing srun to launch the tasks.
The default value of PMI_TIME is 500 and this is the number of
microseconds alloted to transmit each key-pair.
We have executed up to 16,000 tasks with a value of PMI_TIME=4000.
MPICH-2が使用されている場合、srunコマンドはアプリケーションのブートストラップに使用されるキーペアを管理します。プロセッサの速度とアーキテクチャによっては、キーペア情報の通信にさらに時間がかかる場合があります。これは、srunを実行してタスクを起動する前に、環境変数PMI_TIMEを設定することで実行できます。PMI_TIMEのデフォルト値は500で、これは各キーペアの送信に割り当てられたマイクロ秒数です。PMI_TIME = 4000の値で最大16,000のタスクを実行しました。
The individual slurmd daemons on compute nodes will initiate messages
to the slurmctld daemon only when they start up or when the epilog
completes for a job. When a job allocated a large number of nodes
completes, it can cause a very large number of messages to be sent
by the slurmd daemons on these nodes to the slurmctld daemon all at
the same time. In order to spread this message traffic out over time
and avoid message loss, The EpilogMsgTime parameter may be
used. Note that even if messages are lost, they will be retransmitted,
but this will result in a delay for reallocating resources to new jobs.
計算ノード上の個々のslurmdデーモンは、起動したとき、またはジョブのエピログが完了したときにのみ、slurmctldデーモンへのメッセージを開始します。多数のノードを割り当てられたジョブが完了すると、これらのノードのslurmdデーモンが同時に大量のメッセージをslurmctldデーモンに送信する可能性があります。このメッセージトラフィックを時間をかけて分散し、メッセージの損失を回避するために、EpilogMsgTimeパラメータを使用できます。メッセージが失われた場合でも、メッセージは再送信されますが、これにより、新しいジョブへのリソースの再割り当てが遅延することに注意してください。
Other
Slurm uses hierarchical communications between the slurmd daemons
in order to increase parallelism and improve performance. The
TreeWidth configuration parameter controls the fanout of messages.
The default value is 50, meaning each slurmd daemon can communicate
with up to 50 other slurmd daemons and over 2500 nodes can be contacted
with two message hops.
The default value will work well for most clusters.
Optimal system performance can typically be achieved if TreeWidth
is set to the square root of the number of nodes in the cluster for
systems having no more than 2500 nodes or the cube root for larger
systems.
Slurmは、並列性を高めてパフォーマンスを向上させるために、slurmdデーモン間の階層型通信を使用します。TreeWidth構成パラメーターは、メッセージのファンアウトを制御します。デフォルト値は50です。つまり、各slurmdデーモンは他の最大50のslurmdデーモンと通信でき、2500を超えるノードは2つのメッセージホップで接続できます。デフォルト値は、ほとんどのクラスターで適切に機能します。最適なシステムパフォーマンスは、通常、ツリー幅が2500ノード以下のシステムのクラスター内のノード数の平方根、またはより大きなシステムの立方根に設定されている場合に達成できます。
The srun command automatically increases its open file limit to
the hard limit in order to process all of the standard input and output
connections to the launched tasks. It is recommended that you set the
open file hard limit to 8192 across the cluster.
srunコマンドは、起動されたタスクへのすべての標準入出力接続を処理するために、開いているファイルの制限をハード制限に自動的に増やします。クラスター全体で、オープンファイルのハード制限を8192に設定することをお勧めします。
Last modified 9 October 2019