High Throughput Computing Administration Guide

This document contains Slurm administrator information specifically for high throughput computing, namely the execution of many short jobs.
このドキュメントには、特にハイスループットコンピューティング、つまり多くの短いジョブの実行に関するSlurm管理者情報が含まれています。
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の実用的な知識は、この資料の前提条件と見なす必要があります。

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.
Slurmは、1秒あたり500の単純なバッチジョブを持続的に実行し、はるかに高いレベルでアクティビティを短時間バーストすることも検証されています。
Actual performance depends upon the jobs to be executed plus the hardware and configuration used.
実際のパフォーマンスは、実行するジョブに加えて、使用するハードウェアと構成によって異なります。

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.
いくつかのシステム構成パラメーターは、大量のメッセージのバーストを伴う多数のオープンファイルおよびTCP接続をサポートするために変更が必要な場合があります。
Changes can be made using the /etc/rc.d/rc.local or /etc/sysctl.conf script to preserve changes after reboot.
/etc/rc.d/rc.localまたは/etc/sysctl.confスクリプトを使用して変更を加え、再起動後の変更を保持できます。
In either case, you can write values directly into these files (e.g. "echo 32832 > /proc/sys/fs/file-max").
いずれの場合も、これらのファイルに直接値を書き込むことができます（例：「echo32832＞ / proc / sys / fs / file-max」）。

• /proc/sys/fs/file-max: The maximum number of concurrently open files.
  / proc / sys / fs / file-max：同時に開くファイルの最大数。
  We recommend a limit of at least 32,832.
  少なくとも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.
  / proc / sys / net / ipv4 / tcp_max_syn_backlog：3ウェイハンドシェイクで3番目のパケットをまだ取得していないメモリに保持するSYN要求の最大数。
  The default value is 1024 for systems with more than 128Mb of memory, and 128 for low memory machines.
  デフォルト値は、128Mbを超えるメモリを備えたシステムの場合は1024、メモリの少ないマシンの場合は128です。
  If server suffers of overload, try to increase this number.
  サーバーが過負荷になっている場合は、この数を増やしてみてください。
  
• /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.
  / proc / sys / net / ipv4 / tcp_syncookies：特定のソケットのカーネルsynバックログキューがオーバーフローしたときに、syncookieをホストに送信するために使用されます。
  The default value is 0, which disables this functionality.
  デフォルト値は0で、この機能は無効になっています。
  Set the value to 1.
  値を1に設定します。
  
• /proc/sys/net/ipv4/tcp_synack_retries: How many times to retransmit the SYN,ACK reply to an SYN request.
  / proc / sys / net / ipv4 / tcp_synack_retries：SYN要求にSYN、ACK応答を再送信する回数。
  In other words, this tells the system how many times to try to establish a passive TCP connection that was started by another host.
  つまり、これは、別のホストによって開始されたパッシブTCP接続の確立を試行する回数をシステムに通知します。
  This variable takes an integer value, but should under no circumstances be larger than 255.
  この変数は整数値を取りますが、いかなる状況でも255を超えてはなりません。
  Each retransmission will take approximately 30 to 40 seconds.
  各再送信には約30〜40秒かかります。
  The default value of 5, which results in a timeout of passive TCP connections of approximately 180 seconds and is generally satisfactory.
  デフォルト値の5は、パッシブTCP接続のタイムアウトが約180秒になり、通常は十分です。
  
• /proc/sys/net/core/somaxconn: Limit of socket listen() backlog, known in userspace as SOMAXCONN.
  / proc / sys / net / core / somaxconn：ソケットlisten（）バックログの制限。ユーザースペースではSOMAXCONNとして知られています。
  Defaults to 128.
  デフォルトは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.
  たとえば、1024リクエストのバーストをサポートするには、somaxconnを1024に設定します。
  
• /proc/sys/net/ipv4/ip_local_port_range: Identify the ephermeral ports available, which are used for many Slurm communications.
  / proc / sys / net / ipv4 / ip_local_port_range：多くのSlurm通信に使用される利用可能なエフェメラルポートを特定します。
  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.
  たとえば、その範囲のポートを使用可能にするには、値「3276865535」をip_local_port_rangeファイルに書き込みます。
  

The transmit queue length (txqueuelen) may also need to be modified using the ifconfig command.
送信キューの長さ（txqueuelen）も、ifconfigコマンドを使用して変更する必要がある場合があります。
A value of 4096 has been found to work well for one site with a very large cluster (e.g. "ifconfig txqueuelen 4096").
4096の値は、クラスターが非常に大きい1つのサイト（「ifconfigtxqueuelen4096」など）で適切に機能することがわかっています。

Munge configuration

By default the Munge daemon runs with two threads, but a higher thread count can improve its throughput.
デフォルトでは、Mungeデーモンは2つのスレッドで実行されますが、スレッド数を増やすとスループットが向上します。
We suggest starting the Munge daemon with ten threads for high throughput support (e.g. "munged --num-threads 10").
高スループットをサポートするために、Mungeデーモンを10スレッドで開始することをお勧めします（例：「munged--num-threads10」）。

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.
ハイスループットコンピューティングのニーズを反映するために、いくつかのSlurm構成パラメーターを調整する必要があります。
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.
以下で説明する変更は、すべての環境で可能であるとは限りませんが、これらは、スループットを向上させるために検討する必要のある構成オプションです。

• AccountingStorageType: Disabling storing of accounting by using the accounting_storage/none plugin.
  AccountingStorageType：accounting_storage / noneプラグインを使用してアカウンティングの保存を無効にします。
  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
  SlurmDBDを使用する場合は、slurmdbd.confでCommitDelayオプションを設定することで、高速化を実現できます。
  
• JobAcctGatherType: Disabling the collection of job accounting information will improve job throughput.
  JobAcctGatherType：ジョブアカウンティング情報の収集を無効にすると、ジョブのスループットが向上します。
  Disable collection of accounting by using the jobacct_gather/none plugin.
  jobacct_gather / noneプラグインを使用して、アカウンティングの収集を無効にします。
  
• JobCompType: Disabling recording of job completion information will improve job throughput.
  JobCompType：ジョブ完了情報の記録を無効にすると、ジョブのスループットが向上します。
  Disable recording of job completion information by using the jobcomp/none plugin.
  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]).
  MaxJobCount：任意の時点（保留中、実行中、一時停止中、または完了[一時的]）でslurmctldデーモンレコードに含まれる可能性のあるジョブの数を制御します。
  The default value is 10,000.
  デフォルト値は10,000です。
  
• MessageTimeout: Controls how long to wait for a response to messages.
  MessageTimeout：メッセージへの応答を待機する時間を制御します。
  The default value is 10 seconds.
  デフォルト値は10秒です。
  While the slurmctld daemon is highly threaded, its responsiveness is load dependent.
  slurmctldデーモンは高度にスレッド化されていますが、その応答性は負荷に依存します。
  This value might need to be increased somewhat.
  この値をいくらか増やす必要があるかもしれません。
  
• 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.
  MinJobAge：完了したジョブのレコードをslurmctldメモリからパージして、squeueコマンドを使用して表示できないようにするまでの時間を制御します。
  The record of jobs run will be preserved in accounting records and logs.
  実行されたジョブの記録は、アカウンティングレコードとログに保存されます。
  The default value is 300 seconds.
  デフォルト値は300秒です。
  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.
  古いジョブのアカウンティングレコードを使用すると、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.
    オプションbatch_sched_delayを設定すると、バッチジョブのスケジューリングを遅らせることができる期間を制御できます。
    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.
    デフォルト値は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.
    オプションdeferを設定すると、ジョブの送信時に各ジョブを個別にスケジュールすることを回避できますが、複数のジョブを同時にスケジュールできるようになるまで延期します。
    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.
    sched_min_intervalは、スケジューリングロジックの実行頻度を制御するためのさらに別の構成パラメーターです。
    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_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（マイクロ秒）で100個のジョブが2秒の時間枠内に送信された場合、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.
    default_queue_depth構成パラメーターは、スケジューリングロジックの実行頻度を制御するだけでなく、各スケジューラーの反復で開始されると見なされるジョブの数を制御します。
    The default value of default_queue_depth is 100 (jobs), which should be fine in most cases.
    default_queue_depthのデフォルト値は100（ジョブ）です。これはほとんどの場合問題ありません。
    
  • The sched/backfill plugin has relatively high overhead if used with large numbers of job.
    sched / backfillプラグインは、多数のジョブで使用される場合、比較的高いオーバーヘッドがあります。
    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).
    bf_max_job_testを適度なサイズ（たとえば100ジョブ以下）に構成し、bf_intervalを30秒以上に構成すると、バックフィルスケジューリングのオーバーヘッドが制限されます（注：これらのパラメーターの両方でデフォルト値で問題ありません）。
    Other backfill options available for tuning backfill scheduling include bf_max_job_user, bf_resolution and bf_window.
    バックフィルスケジューリングの調整に使用できるその他のバックフィルオプションには、bf_max_job_user、bf_resolution、およびbf_windowがあります。
    See the slurm.conf man page for details.
    詳細については、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.
    1つのクラスターで1秒あたり数百のジョブを継続的に実行するために現在使用されているスケジューリングパラメーターのセットを次に示します。
    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.
    すべての環境が異なり、このパラメーターのセットがすべての場合にうまく機能するとは限りませんが、それは良い出発点として役立つ可能性があることに注意してください。
    
  • 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
• SchedulerType: If most jobs are short lived then use of the sched/builtin plugin is recommended.
  SchedulerType：ほとんどのジョブが短命である場合は、sched / builtinプラグインの使用をお勧めします。
  This manages a queue of jobs on a First-In-First-Out (FIFO) basis and eliminates logic used to sort the queue by priority.
  これにより、先入れ先出し（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.
  SlurmctldPort：上記のSOMAXCONN制限を超えたためにオペレーティングシステムによって着信メッセージが破棄されないようにするために、複数のポートで着信メッセージを受け入れるようにslurmctldデーモンを構成することが望ましいです。
  Using between two and ten ports is suggested when large numbers of simultaneous requests are to be supported.
  多数の同時リクエストをサポートする場合は、2〜10個のポートを使用することをお勧めします。
  
• PrologSlurmctld/EpilogSlurmctld: Neither of these is recommended for a high throughput environment.
  PrologSlurmctld / EpilogSlurmctld：これらのどちらも高スループット環境には推奨されません。
  When they are enabled a separate slurmctld thread has to be created for every job start (or task for a job array).
  それらが有効になっている場合、ジョブの開始（またはジョブ配列のタスク）ごとに個別のslurmctldスレッドを作成する必要があります。
  Current architecture requires acquisition of a job write lock in every thread, which is a costly operation that severely limits scheduler throughput.
  現在のアーキテクチャでは、すべてのスレッドでジョブ書き込みロックを取得する必要があります。これは、スケジューラのスループットを大幅に制限するコストのかかる操作です。
  
• SlurmctldDebug: More detailed logging will decrease system throughput.
  SlurmctldDebug：より詳細なロギングは、システムスループットを低下させます。
  Set to 2 (log errors only) or 3 (general information logging).
  2（ログエラーのみ）または3（一般情報ログ）に設定します。
  Each increment in the logging level will increase the number of message by a factor of about 3.
  ロギングレベルが増加するたびに、メッセージの数が約3倍に増加します。
  
• SlurmdDebug: More detailed logging will decrease system throughput.
  SlurmdDebug：より詳細なロギングは、システムスループットを低下させます。
  Set to 2 (log errors only) or 3 (general information logging).
  2（ログエラーのみ）または3（一般情報ログ）に設定します。
  Each increment in the logging level will increase the number of message by a factor of about 3.
  ロギングレベルが増加するたびに、メッセージの数が約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.
  TaskPlugin：他の選択肢よりも遅いConstrainRAMSpaceの組み合わせでtask / cgroupを使用することは避けてください。
  On the same note task/affinity does not appear to add any measurable overhead.
  同じメモで、タスク/アフィニティは測定可能なオーバーヘッドを追加するようには見えません。
  Using task/affinity for affinity is advised in any case.
  いずれの場合も、アフィニティにタスク/アフィニティを使用することをお勧めします。
  
• 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.
slurmdbd.confで「Purge *」オプションを設定して、古いデータを消去することも検討してください。
A Typical configuration would look like this...
典型的な構成は次のようになります...

• PurgeEventAfter=12months
• PurgeJobAfter=12months
• PurgeResvAfter=2months
• PurgeStepAfter=2months
• PurgeSuspendAfter=1month
• PurgeTXNAfter=12months
• PurgeUsageAfter=12months

Last modified 5 December 2018