High Throughput Computing Administration Guide
This document contains Slurm administrator information specifically
for high throughput computing, namely the execution of many short jobs.
Getting optimal performance for high throughput computing does require
some tuning and this document should help you off to a good start.
A working knowledge of Slurm should be considered a prerequisite
for this material.
このドキュメントには、特に高スループットコンピューティング、つまり多くの短いジョブの実行に関するSlurm管理者情報が含まれています。ハイスループットコンピューティングの最適なパフォーマンスを得るには、多少の調整が必要です。このドキュメントは、良いスタートを切るのに役立ちます。Slurmの実用的な知識は、この資料の前提条件と見なされます。
Performance Results
Slurm has also been validated to execute 500 simple batch jobs per second
on a sustained basis with short bursts of activity at a much higher level.
Actual performance depends upon the jobs to be executed plus the hardware and
configuration used.
Slurmは、非常に高いレベルのアクティビティの短いバーストで、継続的に毎秒500の単純なバッチジョブを実行することも検証されています。実際のパフォーマンスは、実行するジョブに加えて、使用するハードウェアと構成によって異なります。
System configuration
Several system configuration parameters may require modification 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接続をサポートするために変更が必要になる場合があります。/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:
The maximum number of SYN requests to keep in memory that we have yet to get
the third packet in a 3-way handshake from.
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：3ウェイハンドシェイクで3番目のパケットをまだ取得していない、メモリに保持するSYNリクエストの最大数。デフォルト値は、128Mbを超えるメモリを搭載したシステムの場合は1024、低メモリマシンの場合は128です。サーバーが過負荷になっている場合は、この数を増やしてみてください。 - /proc/sys/net/ipv4/tcp_syncookies:
Used to send out syncookies to hosts when the kernels syn backlog queue
for a specific socket is overflowed.
The default value is 0, which disables this functionality.
Set the value to 1.
/ proc / sys / net / ipv4 / tcp_syncookies：特定のソケットのカーネルsynバックログキューがオーバーフローしたときに、syncookiesをホストに送信するために使用されます。デフォルト値は0で、この機能は無効になっています。値を1に設定します。
- /proc/sys/net/ipv4/tcp_synack_retries:
How many times to retransmit the SYN,ACK reply to an SYN request.
In other words, this tells the system how many times to try to establish a
passive TCP connection that was started by another host.
This variable takes an integer value, but should under no circumstances be
larger than 255.
/ proc / sys / net / ipv4 / tcp_synack_retries：SYN要求に対するSYN、ACK応答を再送信する回数。つまり、これは、別のホストによって開始されたパッシブTCP接続の確立を何回試行するかをシステムに通知します。この変数は整数値を取りますが、決して255を超えてはなりません。
Each retransmission will take approximately 30 to 40 seconds. The default value of 5, which results in a timeout of passive TCP connections of approximately 180 seconds and is generally satisfactory.
各再送信には約30〜40秒かかります。デフォルト値の5です。これにより、パッシブTCP接続のタイムアウトが約180秒になり、通常は問題ありません。
- /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に設定します。 - /proc/sys/net/ipv4/ip_local_port_range:
Identify the ephermeral ports available, which are used for many Slurm
communications. The value may be raised to support a high volume of
communications.
For example, write the value "32768 65535" into the ip_local_port_range file
in order to make that range of ports available.
/ proc / sys / net / ipv4 / ip_local_port_range：多くのSlurm通信で使用される、使用可能なEphermeralポートを特定します。この値は、大量の通信をサポートするために上げることができます。たとえば、その範囲のポートを使用可能にするために、値「32768 65535」をip_local_port_rangeファイルに書き込みます。
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」）。
Munge configuration
By default the Munge daemon runs with two threads, but a higher thread count
can improve its throughput. We suggest starting the Munge daemon with ten
threads for high throughput support (e.g. "munged --num-threads 10").
デフォルトでは、Mungeデーモンは2つのスレッドで実行されますが、スレッド数を増やすと、スループットが向上します。高スループットをサポートするために、Mungeデーモンを10スレッドで起動することをお勧めします（「munged --num-threads 10」など）。
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値は、メモリー・サイズ、オープン・ファイル数、およびスタック・サイズに対して非常に高く設定する必要があります。
Slurm Configuration
Several Slurm configuration parameters should be adjusted to
reflect the needs of high throughput computing. The changes described below
will not be possible in all environments, but these are the configuration
options that you may want to consider for higher throughput.
高スループットコンピューティングのニーズを反映するために、いくつかのSlurm構成パラメーターを調整する必要があります。以下で説明する変更はすべての環境で可能であるとは限りませんが、これらはスループットを向上させるために検討する必要がある構成オプションです。
- AccountingStorageType:
Disabling storing of accounting by using the accounting_storage/none
plugin. Turning accounting off provides minimal improvement in performance.
If using the SlurmDBD increased speedup can be achieved by setting the
CommitDelay option in the slurmdbd.conf
AccountingStorageType：accounting_storage / noneプラグインを使用してアカウンティングの保存を無効にします。アカウンティングをオフにすると、パフォーマンスの向上は最小限になります。SlurmDBDを使用している場合、slurmdbd.confのCommitDelayオプションを設定することでスピードアップを実現できます。 - JobAcctGatherType:
Disabling the collection of job accounting information will improve job
throughput. Disable collection of accounting by using the
jobacct_gather/none plugin.
JobAcctGatherType：ジョブアカウンティング情報の収集を無効にすると、ジョブのスループットが向上します。jobacct_gather / noneプラグインを使用して、アカウンティングの収集を無効にします。 - JobCompType:
Disabling recording of job completion information will improve job
throughput. Disable recording of job completion information by using the
jobcomp/none plugin.
JobCompType：ジョブ完了情報の記録を無効にすると、ジョブのスループットが向上します。jobcomp / noneプラグインを使用して、ジョブ完了情報の記録を無効にします。 - MaxJobCount:
Controls how many jobs may be in the slurmctld daemon records at any
point in time (pending, running, suspended or completed[temporarily]).
The default value is 10,000.
MaxJobCount：任意の時点（保留中、実行中、一時停止中、または完了済み[一時的]）でslurmctldデーモンレコードにあるジョブの数を制御します。デフォルト値は10,000です。 - MessageTimeout:
Controls how long to wait for a response to messages.
The default value is 10 seconds.
While the slurmctld daemon is highly threaded, its responsiveness
is load dependent. This value might need to be increased somewhat.
MessageTimeout：メッセージへの応答を待つ時間を制御します。デフォルト値は10秒です。slurmctldデーモンは高度にスレッド化されていますが、その応答性は負荷に依存します。この値は、多少増やす必要がある場合があります。 - MinJobAge:
Controls how soon the record of a completed job can be purged from the
slurmctld memory and thus not visible using the squeue command.
The record of jobs run will be preserved in accounting records and logs.
The default value is 300 seconds. The value should be reduced to a few
seconds if possible. Use of accounting records for older jobs can increase
the job throughput rate compared with retaining old jobs in the memory of
the slurmctld daemon.
MinJobAge：完了したジョブのレコードがslurmctldメモリからパージされ、squeueコマンドを使用して表示されなくなるまでの時間を制御します。実行されたジョブの記録は、会計記録とログに保存されます。デフォルト値は300秒です。可能であれば、値を数秒に減らす必要があります。古いジョブのアカウンティングレコードを使用すると、slurmctldデーモンのメモリに古いジョブを保持する場合と比較して、ジョブのスループット率が向上します。 - PriorityType:
The priority/builtin is considerably faster than other options, but
schedules jobs only on a First In First Out (FIFO) basis.
PriorityType：優先度/ビルドは他のオプションよりもかなり高速ですが、ジョブは先入れ先出し（FIFO）ベースでのみスケジュールされます。 - SchedulerParameters:
Many scheduling parameters are available.
SchedulerParameters：多くのスケジューリングパラメータを使用できます。
- Setting option batch_sched_delay will control how long the
scheduling of batch jobs can be delayed. This effects only batch jobs.
For example, if many jobs are submitted each second, the overhead of
trying to schedule each one will adversely impact the rate at which jobs
can be submitted. The default value is 3 seconds.
オプションbatch_sched_delayを設定すると、バッチジョブのスケジュールを遅らせることができる時間を制御します。これはバッチジョブにのみ影響します。たとえば、毎秒多くのジョブが送信される場合、各ジョブをスケジュールしようとするオーバーヘッドは、ジョブを送信できるレートに悪影響を及ぼします。デフォルト値は3秒です。 - Setting option defer will avoid attempting to schedule each job
individually at job submit time, but defer it until a later time when
scheduling multiple jobs simultaneously may be possible.
This option may improve system responsiveness when large numbers of jobs
(many hundreds) are submitted at the same time, but it will delay the
initiation time of individual jobs.
オプションの据え置きを設定すると、ジョブのサブミット時に各ジョブを個別にスケジュールしようとする試みが回避されますが、複数のジョブを同時にスケジュールできる後の時刻まで延期することができます。このオプションを使用すると、多数のジョブ（数百）が同時に送信された場合のシステムの応答性が向上しますが、個々のジョブの開始時間が遅くなります。 - sched_min_interval is yet another configuration parameter to control
how frequently the scheduling logic runs. It can still be triggered on each
job submit, job termination, or other state change which could permit a new
job to be started. However that triggering does not cause the scheduling logic
to be started immediately, but only within the configured sched_interval.
sched_min_intervalは、スケジューリングロジックの実行頻度を制御するためのさらに別の構成パラメーターです。それでも、ジョブのサブミット、ジョブの終了、または新しいジョブの開始を許可する可能性のあるその他の状態変化のたびにトリガーできます。ただし、そのトリガーによってスケジューリングロジックがすぐに開始されるのではなく、構成されたsched_interval内でのみ開始されます。
For example, if sched_min_interval=2000000 (microseconds) and 100 jobs are submitted within a 2 second time window, then the scheduling logic will be executed one time rather than 100 times if sched_min_interval was set to 0 (no delay).
たとえば、sched_min_interval = 2000000（マイクロ秒）で、2秒の時間枠内に100個のジョブが送信された場合、sched_min_intervalが0（遅延なし）に設定されていれば、スケジューリングロジックは100回ではなく1回実行されます。 - Besides controlling how frequently the scheduling logic is executed, the
default_queue_depth configuration parameter controls how many jobs are
considered to be started in each scheduler iteration. The default value of
default_queue_depth is 100 (jobs), which should be fine in most cases.
スケジューリングロジックが実行される頻度を制御することに加えて、default_queue_depth構成パラメーターは、各スケジューラーの反復で開始されると見なされるジョブの数を制御します。default_queue_depthのデフォルト値は100（ジョブ）で、ほとんどの場合これで十分です。 - The sched/backfill plugin has relatively high overhead if used with
large numbers of job. Configuring bf_max_job_test to a modest size (say 100
jobs or less) and bf_interval to 30 seconds or more will limit the
overhead of backfill scheduling (NOTE: the default values are fine for both
of these parameters). Other backfill options available for tuning backfill
scheduling include bf_max_job_user, bf_resolution and
bf_window. See the slurm.conf man page for details.
sched / backfillプラグインを多数のジョブで使用すると、オーバーヘッドが比較的高くなります。bf_max_job_testを適度なサイズ（たとえば、100ジョブ以下）に設定し、bf_intervalを30秒以上に設定すると、バックフィルスケジューリングのオーバーヘッドが制限されます（注：これらのパラメーターの両方でデフォルト値で問題ありません）。バックフィルスケジュールの調整に使用できる他のバックフィルオプションには、bf_max_job_user、bf_resolution、bf_windowがあります。詳細については、slurm.confのmanページを参照してください。 - A set of scheduling parameters currently used for running hundreds of jobs
per second on a sustained basis on one cluster follows. Note that every
environment is different and this set of parameters will not work well
in every case, but it may serve as a good starting point.
1つのクラスターで1秒あたり数百のジョブを継続的に実行するために現在使用されている一連のスケジューリングパラメーターを次に示します。すべての環境が異なり、このパラメーターのセットがすべての場合に適切に機能するわけではないことに注意してください。ただし、これは良い出発点として役立つ場合があります。 - assoc_limit_continue
- batch_sched_delay=20
- bf_continue
- bf_interval=300
- bf_min_age_reserve=10800
- bf_resolution=600
- bf_yield_interval=1000000
- partition_job_depth=500
- sched_max_job_start=200
- sched_min_interval=2000000
- Setting option batch_sched_delay will control how long the
scheduling of batch jobs can be delayed. This effects only batch jobs.
For example, if many jobs are submitted each second, the overhead of
trying to schedule each one will adversely impact the rate at which jobs
can be submitted. The default value is 3 seconds.
- SchedulerType:
If most jobs are short lived then use of the sched/builtin plugin is
recommended. This manages a queue of jobs on a First-In-First-Out (FIFO) basis
and eliminates logic used to sort the queue by priority.
SchedulerType：ほとんどのジョブが短命である場合、sched / builtinプラグインの使用が推奨されます。これは、ジョブのキューを先入れ先出し（FIFO）ベースで管理し、キューを優先順位でソートするために使用されるロジックを排除します。
- SlurmctldPort:
It is desirable to configure the slurmctld daemon to accept incoming
messages on more than one port in order to avoid having incoming messages
discarded by the operating system due to exceeding the SOMAXCONN limit
described above. Using between two and ten ports is suggested when large
numbers of simultaneous requests are to be supported.
SlurmctldPort：上記のSOMAXCONN制限を超えたためにオペレーティングシステムによって着信メッセージが破棄されるのを避けるために、複数のポートで着信メッセージを受け入れるようにslurmctldデーモンを構成することが望ましいです。多数の同時リクエストをサポートする場合は、2〜10個のポートを使用することをお勧めします。 - PrologSlurmctld/EpilogSlurmctld:
Neither of these is recommended for a high throughput environment. When they
are enabled a separate slurmctld thread has to be created for every job start
(or task for a job array).
Current architecture requires acquisition of a job write lock in every thread,
which is a costly operation that severely limits scheduler throughput.
PrologSlurmctld / EpilogSlurmctld：これらのいずれも、高スループット環境には推奨されません。有効にすると、ジョブの開始（またはジョブ配列のタスク）ごとに個別のslurmctldスレッドを作成する必要があります。現在のアーキテクチャでは、すべてのスレッドでジョブの書き込みロックを取得する必要があります。これは、スケジューラのスループットを大幅に制限するコストのかかる操作です。
- SlurmctldDebug:
More detailed logging will decrease system throughput. Set to 2 (log errors
only) or 3 (general information logging). Each increment in the logging level
will increase the number of message by a factor of about 3.
SlurmctldDebug：より詳細なログを記録すると、システムのスループットが低下します。2（ログエラーのみ）または3（一般情報ログ）に設定します。ログレベルを1つ上げるごとに、メッセージ数が約3倍になります。 - SlurmdDebug:
More detailed logging will decrease system throughput. Set to 2 (log errors
only) or 3 (general information logging). Each increment in the logging level
will increase the number of message by a factor of about 3.
SlurmdDebug：より詳細なロギングにより、システムのスループットが低下します。2（ログエラーのみ）または3（一般情報ログ）に設定します。ログレベルを1つ上げるごとに、メッセージ数が約3倍になります。 - SlurmdLogFile:
Writing to local storage is recommended.
SlurmdLogFile：ローカルストレージへの書き込みをお勧めします。 - TaskPlugin:
Avoid using task/cgroup with the combination of ConstrainRAMSpace
it is slower than other alternatives. On the same note task/affinity
does not appear to add any measurable overhead. Using task/affinity for
affinity is advised in any case.
TaskPlugin：他の選択肢よりも遅いConstrainRAMSpaceの組み合わせでtask / cgroupを使用しないでください。同じように、タスク/アフィニティは測定可能なオーバーヘッドを追加するようには見えません。どんな場合でも、アフィニティにtask / affinityを使用することをお勧めします。 - Other: Configure logging, accounting and other overhead to a minimum
appropriate for your environment.
その他：ロギング、アカウンティング、その他のオーバーヘッドを環境に適した最小限に設定します。
SlurmDBD Configuration
Turning accounting off provides a minimal improvement in performance.
If using SlurmDBD increased speedup can be achieved by setting the CommitDelay
option in the slurmdbd.conf
アカウンティングをオフにすると、パフォーマンスの向上は最小限になります。SlurmDBDを使用している場合、slurmdbd.confのCommitDelayオプションを設定することでスピードアップを実現できます。
You might also consider setting the 'Purge*' options in your
slurmdbd.conf to clear out old Data. A Typical configuration would
look like this...
古いデータを消去するために、slurmdbd.confで「Purge *」オプションを設定することも検討してください。典型的な構成は次のようになります...
- PurgeEventAfter=12months
- PurgeJobAfter=12months
- PurgeResvAfter=2months
- PurgeStepAfter=2months
- PurgeSuspendAfter=1month
- PurgeTXNAfter=12months
- PurgeUsageAfter=12months
Last modified 5 December 2018