6.6. PostgreSQL のチューニング
PostgreSQL は、Satellite が実行するさまざまなタスクの永続的なコンテキストを保存するために、Satellite によって使用される SQL ベースの主要なデータベースです。このデータベースは、Satellite のスムーズな動作に必要なデータを提供するために、通常、広範に使用されています。これにより、PostgreSQL は頻繁に使用されるプロセスになり、調整すると、Satellite の全体的な運用レスポンスに多くの利点がもたらされます。
一連の調整を PostgreSQL に適用して、応答時間を改善することができます。これにより、postgresql.conf ファイルが変更されます。
手順
/etc/foreman-installer/custom-hiera.yamlを追加して PostgreSQL をチューニングします。postgresql::server::config_entries: max_connections: 1000 shared_buffers: 2GB work_mem: 8MB autovacuum_vacuum_cost_limit: 2000
これを使用すると、チューニングプロファイルに関係なく、Satellite インスタンスを効果的にチューニングできます。
- 変更を Satellite Server に適用します。詳細は、「設定の適用」 を参照してください。
上記のチューニング設定には、変更した特定のキーのセットがあります。
-
max_connections: このキーは、実行中の PostgreSQL プロセスが受け入れることができる接続の最大数を定義します。 -
shared_buffers: 共有バッファーは、さまざまなデータベース操作のデータを格納するために PostgreSQL 内のすべてのアクティブな接続によって使用されるメモリーを定義します。このキーの最適な値は、Satellite で実行される操作の頻度に応じて、2 GiB からシステムメモリー合計の 25% までの間で変動します。 -
work_mem: work_mem は、PostgreSQL のプロセスごとに割り当てられるメモリーであり、プロセスによって実行されている操作の中間結果を格納するために使用されます。この値を 8 MB に設定すれば、Satellite でのほとんどの集中的な操作に十分対応できます。 -
autovacuum_vacuum_cost_limit: このキーは、データベースリレーション内のデッドタプルをクリーンアップする autovacuum プロセス内のバキューム操作のコスト制限値を定義します。コスト制限は、プロセスによる 1 回の実行で処理できるタプルの数を定義します。Red Hat は、medium、large、extra-large、および extra-extra-large のプロファイルと同様に、Satellite が PostgreSQL サーバープロセスに加える一般的な負荷に基づいて、この値を2000に設定することを推奨します。
詳細は、BZ1867311: Upgrade fails when checkpoint_segments postgres parameter configured を参照してください。
6.6.1. 生の DB パフォーマンスのベンチマーク
キャンドルピン、フォアマン、パルプの両方のディスクスペースのトップテーブルサイズのリストを取得するには、satellite-support リポジトリーの postgres-size-report スクリプトを確認してください。
PGbench ユーティリティー (PostgreSQL データディレクトリー /var/opt/rh/rh-postgresql12/lib/pgsql/ ディレクトリーのサイズを 100 GiB またはベンチマークの実行に必要なものに変更する必要がある場合があります) を使用して、システムの PostgreSQL パフォーマンスを測定できます。yum install postgresql-contrib を使用してインストールします。詳細については、github.com/RedHatSatellite/satellite-support を参照してください。
PostgreSQL データディレクトリーのファイルシステムの選択も重要になる場合があります。
- 有効なバックアップがない状態で、実稼働システムでテストを実行しないでください。
- テストを開始する前に、データベースファイルのサイズを確認してください。非常に小さなデータベースでテストしても、意味のある結果は得られません。たとえば、DB がわずか 20 GiB で、バッファープールが 32 GiB の場合、データは完全にバッファリングされるため、多数の接続で問題が発生することはありません。
