Amazon RDS for PostgreSQL での PostgreSQL 自動バキュームの使用
autovacuum 機能を使用して、PostgreSQL DB インスタンスの状態を維持することを強くお勧めします。autovacuum は、VACUUM コマンドと ANALYZE コマンドのスタートを自動化します。自動バキュームが、多数のタプルが挿入、更新、または削除されたテーブルを確認します。確認後、自動バキュームは PostgreSQL データベースから古いデータやタプルを削除することで、ストレージを再利用します。
デフォルトの PostgreSQL DB パラメータグループのいずれかを使用して作成した RDS for PostgreSQL DB インスタンスでは、デフォルトで自動バキュームがオンになっています。autovacuum 機能に関連するその他の設定パラメータもデフォルトで設定されます。これらのデフォルト値は汎用的であるため、特定のワークロードに対して、autovacuum 機能に関連付けられているパラメータの一部をチューニングすることには利点があります。
次に、autovacuum の詳細と、RDS for PostgreSQL DB インスタンスでそのパラメータの一部をチューニングする方法について説明します。概要については、「PostgreSQL を使用するためのベストプラクティス」を参照してください。
トピック
autovacuum のメモリを割り当てる
autovacuum のパフォーマンスに影響を与える最も重要なパラメータの 1 つは、autovacuum_work_mem
autovacuum_work_mem
パラメータは -1 に設定されており、maintenance_work_mem
の設定が代わりに使用されていることを示します。他のすべてのバージョンでは、autovacuum_work_mem
は GREATEST({DBInstanceClassMemory/32768}, 65536) によって決定されます。
手動バキュームオペレーションは常に maintenance_work_mem
設定を使用し、デフォルト設定は GREATEST({DBInstanceClassMemory/63963136*1024}, 65536) です。また、より的を絞った手動 VACUUM
オペレーションを実現するために、SET
のコマンドを使用してセッションレベルで調整することもできます。
autovacuum_work_mem
は、インデックスをバキュームするためのデッドタプル (pg_stat_all_tables.n_dead_tup
) の識別子を保持するため、autovacuum のメモリを決定します。
計算を実行して autovacuum_work_mem
パラメータの値を決定するときは、次の点に注意してください。
-
パラメータの設定値が低すぎると、バキューム処理が完了するまでにテーブルを複数回スキャンすることが必要になる場合があります。このような複数のスキャンは、パフォーマンスに悪影響を及ぼすことがあります。より大きなインスタンスでは、
maintenance_work_mem
またはautovacuum_work_mem
を少なくとも 1 GB に設定することで、デッドタプル数が多いテーブルをバキュームするためのパフォーマンスが向上します。ただし、PostgreSQL バージョン 16 以前では、バキュームのメモリ使用量は 1 GB に制限されています。これは、1 回のパスで約 1 億 7,900 万個のデッドタプルを処理するのに十分な量です。テーブルのデッドタプルがこれよりも多い場合、バキュームはテーブルのインデックスを複数回通過させる必要があり、所要時間が大幅に増加します。PostgreSQL バージョン 17 以降、1 GB の制限はなく、自動バキュームは基数ツリーを使用して 1 億 7,900 万を超えるタプルを処理できます。タプル識別子のサイズは 6 バイトです。テーブルのインデックスのバキュームに必要なメモリを推定するには、
pg_stat_all_tables.n_dead_tup
をクエリしてデッドタプル数を求め、この数に 6 を掛けて、1 回のパスでインデックスをバキュームするのに必要なメモリを決定します。以下のクエリを使用できます。SELECT relname AS table_name, n_dead_tup, pg_size_pretty(n_dead_tup * 6) AS estimated_memory FROM pg_stat_all_tables WHERE relname = '
name_of_the_table
'; -
autovacuum_work_mem
パラメータは、autovacuum_max_workers
パラメータと連動して機能します。autovacuum_max_workers
間の各ワーカーは、割り当てたメモリを使用できます。小さいテーブルが多数ある場合、autovacuum_max_workers
の割り当てを増やしてautovacuum_work_mem
の割り当てを減らします。大きなテーブル (100 GB 以上) がある場合は、メモリの割り当てを増やしてワーカープロセス数を減らします。最も大きいテーブルを正常に処理するには、十分なメモリを割り当てる必要があります。したがって、ワーカープロセスとメモリの組み合わせが、割り当てるメモリの合計と等しくなることを確認してください。
トランザクション ID の循環の可能性を減らす
autovacuum に関連するパラメータグループの設定は、トランザクション ID の循環を防ぐほどは排除率が高くない場合があります。この問題に対処するために、RDS for PostgreSQL には autovacuum パラメータ値を自動的に適応させるメカニズムが用意されています。適応型 autovacuum は、RDS for PostgreSQL の機能です。トランザクション ID の循環
適応型 autovacuum は、動的パラメータ rds.adaptive_autovacuum
が ON に設定されている RDS for PostgreSQL インスタンスでは、デフォルトでオンになります。この設定をオンにしておくことを強くお勧めします。ただし、autovacuum パラメータのアダプティブチューニングをオフにする場合は、rds.adaptive_autovacuum
パラメータを 0 または OFF に設定します。
トランザクション ID の循環は、Amazon RDS で autovacuum パラメータをチューニングした後でも発生する場合があります。トランザクション ID の循環に対して Amazon CloudWatch アラームを実装することをお勧めします。詳細については、AWS データベースブログの記事「Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL
自動バキュームパラメータのアダプティブチューニングをオンにすると、CloudWatch メトリクス MaximumUsedTransactionIDs
が autovacuum_freeze_max_age
パラメータの値または 500,000,000 のいずれか大きいほうに達したときに、Amazon RDS で自動バキュームパラメータの調整が開始されます。
テーブルでトランザクション ID の循環の傾向が続く場合、Amazon RDS では自動バキュームパラメータの調整が続行されます。続行される調整ごとに、循環を避けるために autovacuum に割り当てられる専用のリソースが増えます。Amazon RDS は、以下の autovacuum 関連のパラメータを更新します。
これらのパラメータが RDS で変更されるのは、新しい値で autovacuum による排除率が高くなる場合に限られます。パラメータは、DB インスタンスのメモリで変更されます。パラメータグループの値は変更されません。現在のメモリ内の設定を確認するには、PostgreSQL の SHOW
これらの自動バキュームパラメータのいずれかが Amazon RDS で変更されると、影響を受ける DB インスタンスでイベントが生成されます。このイベントは、AWS Management Console や Amazon RDS API を介して表示できます。CloudWatch メトリクス MaximumUsedTransactionIDs
がしきい値より低い値に戻ると、Amazon RDS はメモリ内の自動バキューム関連のパラメータをリセットして、パラメータグループで指定されている値に戻します。次に、この変更に対応する別のイベントが生成されます。