Puma ワーカーごとの Puma スレッドの数は、threads_min と threads_max という 2 つの値を使用して設定されます。

threads_min の値は、ワーカーの起動時に各ワーカーが生成するスレッドの数を決定します。その後、同時リクエストが発生し、より多くのスレッドが必要になると、ワーカーは上限である thread_max に達するまでさらに多くのワーカーを生成します。

Puma スレッドが少ないと Satellite Server のメモリー使用量が増えるため、threads_min を thread_max と同じ値に設定することを推奨します。

例として、同時登録テストを使用して、次の 2 つの設定を比較しました。

Puma の最小スレッド数を 16 に設定すると、thread_min=0 と比較してメモリー使用量が約 12% 少なくなります。

Puma のワーカーとスレッドの値を satellite-installer で指定しなかった場合、またはそれらが Satellite 設定に存在しない場合、satellite-installer はバランスの取れたワーカー数を設定します。satellite-installer は次の式に従います。

min(CPU_COUNT * 1.5, RAM_IN_GB - 1.5)

ほとんどの場合はこれで問題ありませんが、使用パターンによっては、(他の Satellite コンポーネントがリソースを使用できるように) Puma 専用のリソースの量を制限するなどの理由で、チューニングが必要になる場合があります。各 Puma ワーカーは約 1 GiB の RAM を消費します。

# cat /etc/systemd/system/foreman.service.d/installer.conf

# systemctl status foreman

「Puma のワーカー数とスレッド数の自動チューニング」 を利用しない場合は、これらの調整パラメーターにカスタム数値を適用できます。以下の例では、2 つのワーカーと、最小 5 つ、最大 5 つのスレッドを使用します。

# satellite-installer \
--foreman-foreman-service-puma-workers=2 \
--foreman-foreman-service-puma-threads-min=5 \
--foreman-foreman-service-puma-threads-max=5

変更を Satellite Server に適用します。詳細は、「設定の適用」 を参照してください。

さまざまなチューニングプロファイルのスレッドとワーカーの設定を推奨するために、Red Hat はさまざまなチューニングプロファイルを使用して、Satellite で Puma チューニングテストを実施しました。このテストで使用した主なテストは、さまざまなワーカー数とスレッド数を使用した、次の組み合わせによる同時登録です。当社の推奨値は、純粋に同時登録のパフォーマンスに基づいているため、正確なユースケースを反映していない可能性があります。たとえば、セットアップが非常にコンテンツ指向で、パブリッシュとプロモートが多い場合は、Pulp と PostgreSQL を優先して Puma によって消費されるリソースを制限することもできます。

ここではワーカー数のチューニングがより重要であり、場合によっては最大 52% のパフォーマンス向上が見られました。インストーラーはデフォルトで最小/最大 5 スレッドを使用しますが、上記の表のすべてのチューニングプロファイルでは、16 スレッドを使用することを推奨します。これは、4 スレッドでのセットアップと比較して、16 スレッドで最大 23% のパフォーマンス向上 (8 で 14%、32 で 10%) が見られたためです。

Red Hat はこの推奨値を明らかにするために、非常に特殊なユースケースである同時登録テストケースを使用しました。これは、(登録だけでなく) よりバランスの取れたユースケースを持つ Satellite では異なる場合があります。デフォルトの最小/最大 5 スレッドを維持することも良い選択です。

この推奨値の根拠となった測定値の一部を以下に示します。

default セットアップ (4 CPU) では 4 - 6 つのワーカーを使用します。ワーカー 5 つの場合は、ワーカー 2 つと比較した場合、約 25% パフォーマンスが向上しました。しかし、ワーカー 8 つの場合は、ワーカー 2 つと比較した場合、パフォーマンスが 8% 低下しました。以下の表を参照してください。

medium セットアップ (8 CPU) では 8 - 12 個のワーカーを使用します。以下の表を参照してください。

32 CPU のセットアップでは 16 - 24 個のワーカーを使用します (これは 90 GiB RAM マシンでテストされました。システムがスワッピングを開始し、メモリーがここでの 1 つの要因となっていることが判明したためです。適切な extra-large には 128 GiB が必要です)。ワーカー数をそれ以上に増やすと、高い同時登録レベルでテストした際に問題が発生したため、このような設定は推奨できません。

CPU が十分にある場合は、ワーカーを追加するとパフォーマンスが向上します。例として、8 CPU と 16 CPU の Satellite セットアップを比較しました。

8 CPU のセットアップでは、ワーカー数を 2 から 16 に変更すると、同時登録時間が 36% 向上しました。16 CPU のセットアップでは、同じ変更で 55% の向上が見られました。

ワーカーを追加すると、Satellite が処理できる同時登録の総数も増やすことができます。私たちの測定では、2 つのワーカーを使用したセットアップで最大 480 の同時登録を処理できましたが、ワーカーを追加すると状況が改善されました。

# satellite-installer \
--foreman-foreman-service-puma-threads-max=5
--foreman-foreman-service-puma-threads-min=5 \
--foreman-foreman-service-puma-workers=2 \

スレッド数が多いほど、ホストを並行して登録する時間を短縮できます。例として、次の 2 つの設定を比較しました。

総スレッド数はそのままにして、使用するワーカー数を増やすと、同時登録のシナリオで約 11% の速度向上が得られます。さらに、ワーカーを追加しても CPU と RAM の消費量は増加しませんでしたが、パフォーマンスは向上しました。

$db_pool の実効値は、自動的に $foreman::foreman_service_puma_threads_max と等しくなるように設定されます。これは $foreman::db_pool と $foreman::foreman_service_puma_threads_max の最大値ですが、どちらもデフォルト値が 5 であるため、最大スレッド数が 5 を超えると、データベース接続プールが自動的に同じ量だけ増加します。

/var/log/foreman/production.log に、ActiveRecord::ConnectionTimeoutError: could not obtain a connection from the pool within 5.000 seconds (waited 5.006 seconds); all pooled connections were in use というエラーが見られたら、この値を増やすことを推奨します。

# grep pool /etc/foreman/database.yml
  pool: 5

自動的に設定される値を利用しない場合は、次のようにカスタムの数値を適用できます。

# satellite-installer --foreman-db-pool 10

変更を Satellite Server に適用します。詳細は、「設定の適用」 を参照してください。

デフォルトでは、HTTPD はプリフォークリクエスト処理メカニズムを使用します。リクエストを処理するプリフォークモデルを使用して、httpd はクライアントによる着信接続を処理するための新しいプロセスを起動します。

apache へのリクエストの数が、着信接続を処理するために起動できる子プロセスの最大数を超えると、httpd によって HTTP 503 サービス使用不可エラーが発生します。処理するプロセスが不足している httpd の中で、着信接続は、Pulp などのコンポーネントが httpd プロセスの可用性に依存しているため、Satellite 側で複数のコンポーネントの障害を引き起こす可能性もあります。

HTTPD プリフォークの設定を調整して、予想されるピーク負荷に基づいて、より多くの同時要求を処理できます。

Satellite への 150 の同時コンテンツホスト登録を処理することを望む可能性があるサーバーのプリフォーク設定の変更例は、次の設定ファイルの例のようになります custom-hiera.yaml ファイルの使用方法を参照してください。これにより設定ファイル /etc/httpd/conf.modules.d/prefork.conf が変更されます):

/etc/foreman-installer/custom-hiera.yaml を変更できます:

apache::mod::prefork::serverlimit: 582
apache::mod::prefork::maxclients: 582
apache::mod::prefork::startservers: 10

チューニングを行うと、Apache httpd はサーバー上で多くのファイル記述子を簡単に開くことができます。これは、ほとんどの Linux システムのデフォルトの制限を超える可能性があります。システムの最大オープンファイル数の上限を超えた結果として発生する可能性のある問題を回避するには、次のファイルとディレクトリーを作成し、以下の例で指定されているようにファイルの内容を設定してください。

デフォルトでは、httpd はイベント要求処理メカニズムを使用します。httpd へのリクエストの数が、着信接続を処理するために起動できる子プロセスの最大数を超えると、httpd で HTTP 503 Service Unavailable エラーが発生します。httpd で処理するプロセスが不足すると、コンポーネントで httpd プロセスを使用できるかどうかに左右されるので、Satellite サービス側の着信接続も複数のコンポーネントで問題が発生します。

httpd イベントの設定を調整して、予想されるピーク負荷に基づいてより多くの同時リクエストを処理できます。

多数のコンテンツホストを備えた katello-agent インフラストラクチャーを使用するデプロイメントでは、qdrouterd の最大オープンファイル数を増やす必要がある場合があります。

qdrouterd のオープンファイル数の上限は、(N x 3) + 100 という式で計算します。N はコンテンツホストの数です。各コンテンツホストはルーターで最大 3 つのファイル記述子を消費する可能性があり、ルーター自体を実行するには 100 個のファイル記述子が必要です。

以下の設定では、Satellite のコンテンツホストを10,000 まで増やすことができます。

多数のコンテンツホストを備えた katello-agent インフラストラクチャーを使用するデプロイメントでは、qpidd の最大オープンファイル数を増やす必要がある場合があります。

qpidd のオープンファイル数の上限は、(N x 4) + 500 という式で計算します。N はコンテンツホストの数です。1 つのコンテンツホストは最大 4 つのファイル記述子を使用する可能性があり、Broker (qpidd のコンポーネント) の操作には 500 個のファイル記述子が必要です。

多数のコンテンツホストを備えた katello-agent インフラストラクチャーを使用するデプロイメントでは、許容される同時 AIO リクエストの最大数を増やす必要がある場合があります。カーネルパラメーター fs.aio-max-nr の値を増やすことで、許容される同時 AIO リクエストの最大数を増やすことができます。

katello-agent を広範囲に使用するインストールを計画している場合は、事前に /var/lib/qpidd に十分なストレージ領域を確保してください。Satellite Server では、1 つのコンテンツホストに対して /var/lib/qpidd のディスク領域が 2 MiB 必要になります。

Red Hat Enterprise Linux 7 のジャーナルに次のエラーが表示される場合があります (journalctl コマンドを使用してアクセスします)。

satellite.example.com qpidd[92464]: [Broker] error Channel exception: not-attached: Channel 2 is not attached(/builddir/build/BUILD/qpid-cpp-0.30/src/qpid/amqp_0_10/SessionHandler.cpp: 39
satellite.example.com qpidd[92464]: [Protocol] error Connectionqpid.10.1.10.1:5671-10.1.10.1:53790 timed out: closing

このエラーメッセージが表示されるのは、qpid がキュー、セッション、および接続の管理オブジェクトを保持し、それらをデフォルトで 10 秒ごとに再利用するためです。同じ ID を持つ同じオブジェクトが作成、削除され、再作成されます。古い管理オブジェクトは削除されていないため、qpid でこのようなエラーが発生します。

mosquitto MQTT サーバーを調整して、接続するホストの数を増やすことができます。

Satellite Server が Script プロバイダーを使用してリモート実行ジョブのプルベースのトランスポートモードで設定されている場合、Capsule Server は新しいジョブに関する通知を MQTT 経由でクライアントに送信します。この通知には、クライアントが実行するはずの実際のワークロードは含まれません。クライアントは、新しいリモート実行ジョブに関する通知を受け取ると、実際のワークロードについて Capsule Server に問い合わせます。ジョブ中、クライアントは定期的にジョブの出力を Capsule Server に送信するため、Capsule Server へのリクエストの数がさらに増加します。

Capsule Server へのこれらのリクエストと、MQTT プロトコルによって許可される高い同時実行性により、Capsule Server で使用可能な接続が枯渇する可能性があります。一部のリクエストが失敗し、リモート実行ジョブの一部の子タスクが応答しなくなる場合があります。これは、実際のジョブのワークロードにも依存します。これは、一部のジョブが Satellite Server に追加の負荷を発生させ、クライアントが Satellite Server に登録されている場合にリソースに対して競合するためです。

これを回避するには、Satellite Server と Capsule Server を次のパラメーターで設定します。

# satellite-installer \
--foreman-proxy-plugin-remote-execution-script-mqtt-rate-limit My_MQTT_Rate_Limit \
--foreman-proxy-plugin-remote-execution-script-mqtt-resend-interval My_MQTT_Resend_Interval \
--foreman-proxy-plugin-remote-execution-script-mqtt-ttl My_MQTT_Time_To_Live

Capsule Server のログは /var/log/foreman-proxy/proxy.log にあります。Capsule Server は Webrick HTTP サーバー (httpd や Puma は関与しません) を使用するため、その容量を増やす簡単な方法はありません。

Candlepin、Foreman、Pulp 用のディスク領域の上位テーブルサイズのリストを取得するには、satellite-support git リポジトリーの postgres-size-report スクリプトを確認してください。

PGbench ユーティリティーを使用して、システムの PostgreSQL パフォーマンスを測定できます (場合によっては、PostgreSQL データディレクトリー /var/lib/pgsql のサイズを 100 GiB またはベンチマークの実行に必要なサイズに変更する必要があります)。このユーティリティーは、dnf install postgresql-contrib を使用してインストールします。詳細は、github.com/RedHatSatellite/satellite-support を参照してください。

PostgreSQL データディレクトリーのファイルシステムの選択も重要になる場合があります。

Red Hat は、複数の Capsule 設定で複数のテストケースを測定しました。

Satellite Server と Capsule Server のダウンロードパフォーマンスを比較したところ、約 5% の速度向上しか見られませんでした。しかし、Capsule Server の主な利点は、コンテンツを地理的に分散したクライアント (または異なるネットワーク内のクライアント) に近づけることや、Satellite Server 自体が処理する必要がある負荷の一部を処理することにあります。小規模なハードウェア設定 (8 CPU および 24 GiB) の Satellite Server は、500 を超える同時クライアントからのダウンロードを処理できませんでしたが、同じハードウェア設定の Capsule Server は、1000 以上のクライアントにサービスを提供できました。

apache::mod::proxy::proxy_timeout: 600