# Amazon Aurora PostgreSQL での PostgreSQL 自動バキュームの使用
<a name="Appendix.PostgreSQL.CommonDBATasks.Autovacuum"></a>

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

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

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

**Topics**
+ [autovacuum のメモリを割り当てる](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [トランザクション ID の循環の可能性を減らす](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [データベース内のテーブルにバキューム処理が必要かどうかの判別](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [現在 autovacuum の対象となっているテーブルの判別](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [Autovacuum が現在実行されているかどうかと実行されている時間の判別](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [手動バキュームフリーズの実行](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [autovacuum の実行中にテーブルのインデックスを再作成する](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [大きなインデックスを使った autovacuum の管理](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [autovacuum に影響を与えるその他のパラメータ](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [テーブルレベルの autovacuum パラメータを設定する](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [自動バキュームおよびバキュームアクティビティのログ記録](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [無効なデータベースでの自動バキュームの動作を理解する](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [Aurora PostgreSQL で積極的なバキュームのブロック要因を特定して解決する](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)

## autovacuum のメモリを割り当てる
<a name="Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory"></a>

autovacuum のパフォーマンスに影響を与える最も重要なパラメータの 1 つは、[https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM) パラメータです。Aurora PostgreSQL バージョン 14 以前では、`autovacuum_work_mem` パラメータは -1 に設定されており、`maintenance_work_mem` の設定が代わりに使用されていることを示します。他のすべてのバージョンでは、`autovacuum_work_mem` は GREATEST(\$1DBInstanceClassMemory/32768\$1, 65536) によって決定されます。

手動バキュームオペレーションは常に `maintenance_work_mem` 設定を使用し、デフォルト設定は GREATEST(\$1DBInstanceClassMemory/63963136\$11024\$1, 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 の循環の可能性を減らす
<a name="Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming"></a>

autovacuum に関連するパラメータグループの設定は、トランザクション ID の循環を防ぐほどは排除率が高くない場合があります。この問題に対処するために、Aurora PostgreSQL には autovacuum パラメータ値を自動的に適応させるメカニズムが用意されています。*適応型 autovacuum* は、Aurora PostgreSQL の機能です。[トランザクション ID の循環](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)に関する詳しい説明については、PostgreSQL ドキュメントを参照してください。

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

トランザクション ID の循環は、Aurora で autovacuum パラメータをチューニングした後でも発生する場合があります。トランザクション ID の循環に対して Amazon CloudWatch アラームを実装することをお勧めします。詳細については、AWS データベースブログの記事「[Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-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 関連のパラメータを更新します。
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+  [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM) 
+  [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME) 

これらのパラメータが RDS で変更されるのは、新しい値で autovacuum による排除率が高くなる場合に限られます。パラメータは、DB インスタンスのメモリで変更されます。パラメータグループの値は変更されません。現在のメモリ内の設定を確認するには、PostgreSQL の [SHOW](https://www.postgresql.org/docs/current/sql-show.html) SQL コマンドを使用します。

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