Amazon Aurora PostgreSQL での PostgreSQL 自動バキュームの使用 - Amazon Aurora
autovacuum のメモリを割り当てるトランザクション ID の循環の可能性を減らす

Amazon Aurora PostgreSQL での PostgreSQL 自動バキュームの使用

autovacuum 機能を使用して、PostgreSQL DB インスタンスの状態を維持することを強くお勧めします。autovacuum は、VACUUM コマンドと ANALYZE コマンドのスタートを自動化します。自動バキュームが、多数のタプルが挿入、更新、または削除されたテーブルを確認します。確認後、自動バキュームは PostgreSQL データベースから古いデータやタプルを削除することで、ストレージを再利用します。

デフォルトの PostgreSQL DB パラメータグループのいずれかを使用して作成した Aurora PostgreSQL DB インスタンスでは、デフォルトで自動バキュームがオンになっています。autovacuum 機能に関連するその他の設定パラメータもデフォルトで設定されます。これらのデフォルト値は汎用的であるため、特定のワークロードに対して、autovacuum 機能に関連付けられているパラメータの一部をチューニングすることには利点があります。

次に、自動バキュームの詳細と、Aurora PostgreSQL DB インスタンスでそのパラメータの一部をチューニングする方法について説明します。

トピック

autovacuum のメモリを割り当てる

autovacuum のパフォーマンスに影響を与える最も重要なパラメータの 1 つは、autovacuum_work_mem パラメータです。Aurora PostgreSQL バージョン 14 以前では、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 の循環を防ぐほどは排除率が高くない場合があります。この問題に対処するために、Aurora PostgreSQL には autovacuum パラメータ値を自動的に適応させるメカニズムが用意されています。適応型自動バキュームは、Aurora PostgreSQL の機能です。トランザクション ID の循環に関する詳しい説明については、PostgreSQL ドキュメントを参照してください。

適応型自動バキュームは、動的パラメータ rds.adaptive_autovacuum が ON に設定されている Aurora PostgreSQL インスタンスでは、デフォルトでオンになります。この設定をオンにしておくことを強くお勧めします。ただし、autovacuum パラメータのアダプティブチューニングをオフにする場合は、rds.adaptive_autovacuum パラメータを 0 または OFF に設定します。

トランザクション ID の循環は、Aurora で自動バキュームパラメータをチューニングした後でも発生する場合があります。トランザクション ID の循環に対して Amazon CloudWatch アラームを実装することをお勧めします。詳細については、AWS データベースブログの記事「Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL」(RDS for PostgreSQL でトランザクション ID の循環に早期警告システムを実装する) を参照してください。

自動バキュームパラメータのアダプティブチューニングをオンにすると、CloudWatch メトリクス MaximumUsedTransactionIDs が autovacuum_freeze_max_age パラメータの値または 500,000,000 のいずれか大きいほうに達したときに、Amazon RDS で自動バキュームパラメータの調整が開始されます。

テーブルでトランザクション ID の循環の傾向が続く場合、Amazon RDS では自動バキュームパラメータの調整が続行されます。続行される調整ごとに、循環を避けるために autovacuum に割り当てられる専用のリソースが増えます。Amazon RDS は、以下の autovacuum 関連のパラメータを更新します。

これらのパラメータが RDS で変更されるのは、新しい値で autovacuum による排除率が高くなる場合に限られます。パラメータは、DB インスタンスのメモリで変更されます。パラメータグループの値は変更されません。現在のメモリ内の設定を確認するには、PostgreSQL の SHOW SQL コマンドを使用します。

これらの自動バキュームパラメータのいずれかが Amazon RDS で変更されると、影響を受ける DB インスタンスでイベントが生成されます。このイベントは、AWS Management Console や Amazon RDS API を介して表示できます。CloudWatch メトリクス MaximumUsedTransactionIDs がしきい値より低い値に戻ると、Amazon RDS はメモリ内の自動バキューム関連のパラメータをリセットして、パラメータグループで指定されている値に戻します。次に、この変更に対応する別のイベントが生成されます。