翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# テーブルのバキューム処理と分析の自動実行
<a name="autovacuum"></a>

自動バキュームは、デッドタプルの*バキューム処理* (クリーンアップ)、ストレージの再利用、統計の収集を自動的に行うデーモンです (つまり、バックグラウンドで実行されます)。データベース内で大きくなったテーブルをチェックし、肥大化を削除してスペースを再利用します。データベースのテーブルとインデックスをモニタリングし、特定の更新または削除オペレーションのしきい値に達したらバキュームジョブに追加します。

自動バキュームは PostgreSQL `VACUUM` および `ANALYZE` コマンドを自動化することでバキューム処理を管理します。`VACUUM` を使用してテーブルの肥大化を削除し、スペースを再利用する一方で、`ANALYZE` を使用してオプティマイザが効果的なプランを作成できるよう統計を更新します。また、`VACUUM` は*バキュームフリーズ*と呼ばれる主要なタスクを実行して、データベース内のトランザクション ID の循環に関する問題を回避します。データベースで更新されたすべての行は、PostgreSQL トランザクション制御メカニズムからトランザクション ID を受け取ります。これらの ID によって、他の同時トランザクションに対する行の可視性が制御されます。トランザクション ID は 32 ビットの数値です。目に見える過去として、常に 20 億個の ID が保持されます。残りの ID (約 22 億個) は、今後実施されるトランザクション用に保持され、現在のトランザクションでは非表示になります。PostgreSQL では、新しいトランザクションの作成時にトランザクションが循環したり、既存の古い行が非表示になったりしないように、古い行のクリーニングと*フリーズ*が必要になることがあります。詳細については、PostgreSQL ドキュメントの「[トランザクション ID 循環の失敗を防ぐ](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)」を参照してください。

自動バキュームが推奨され、デフォルトで有効になっています。パラメータには、以下が含まれます。


|  |  |  |  | 
| --- |--- |--- |--- |
| **パラメータ** | **説明** | **Amazon RDS のデフォルト** | **Aurora のデフォルト** | 
| `autovacuum_vacuum_threshold` | 自動バキュームでバキューム処理する前にテーブルで実行する必要があるタプルの更新または削除オペレーションの最小数。 | 50 オペレーション | 50 オペレーション | 
| `autovacuum_analyze_threshold` | 自動バキュームで分析を実行する前にテーブルで実行する必要があるタプルの挿入、更新、または削除の最小数。 | 50 オペレーション | 50 オペレーション | 
| `autovacuum_vacuum_scale_factor` | 自動バキュームでバキューム処理する前にテーブルで変更する必要があるタプルの割合。 | 0.1 | 0.1 | 
| `autovacuum_analyze_scale_factor` | 自動バキュームで分析を実行する前にテーブルで変更する必要があるタプルの割合。 | 0.05 | 0.05 | 
| `autovacuum_freeze_max_age` | トランザクション ID の循環に関する問題を回避するためにテーブルがバキューム処理される前の、フリーズ ID の最大有効期間。 | 200,000,000 件のトランザクション | 200,000,000 件のトランザクション | 

自動バキュームでは、次のように特定のしきい値式に基づいて処理するテーブルのリストが作成されます。
+ テーブルで `VACUUM` を実行するためのしきい値: 

  ```
  vacuum threshold = autovacuum_vacuum_threshold + (autovacuum_vacuum_scale_factor * Total row count of table)
  ```
+ テーブルで `ANALYZE` を実行するためのしきい値: 

  ```
  analyze threshold = autovacuum_analyze_threshold + (autovacuum_analyze_scale_factor * Total row count of table)
  ```

中小規模のテーブルの場合、デフォルト値で十分です。ただし、データ変更が頻繁に発生するような大きなテーブルでは、デッドタプルの数が多くなります。この場合、自動バキュームによってメンテナンスのためにテーブルが頻繁に処理され、大きなテーブルの処理が終了するまで他のテーブルのメンテナンスが遅延または無視される可能性があります。これを回避するには、次のセクションで説明する autovacuum パラメータを調整できます。

## 自動バキュームのメモリ関連パラメータ
<a name="autovacuum-parameters"></a>

**`autovacuum_max_workers`**

同時に実行できる自動バキュームプロセス (自動バキュームランチャーを除く) の最大数を指定します。このパラメータは、サーバーを起動するときにのみ設定できます。自動バキュームプロセスが大きなテーブルでビジー状態の場合、このパラメータを使用して他のテーブルのクリーンアップを実行できます。

**`maintenance_work_mem`**

メンテナンスオペレーション (`VACUUM`、`CREATE INDEX`、`ALTER` など) で使用されるメモリの最大量を指定します。Amazon RDS と Aurora では、式 `GREATEST({DBInstanceClassMemory/63963136*1024},65536)` を使用してインスタンスクラスに基づきメモリが割り当てられます。自動バキュームを実行する場合、その計算値を割り当てることができるのは最大で `autovacuum_max_workers` 回までとなるため、値を高く設定しすぎないように注意してください。これを制御するには、`autovacuum_work_mem` を個別に設定できます。

**`autovacuum_work_mem`**

各自動バキュームワーカープロセスで使用するメモリの最大量を設定します。このパラメータのデフォルトは -1 です。これは、代わりに `maintenance_work_mem` の値を使用する必要があることを示します。

autovacuum メモリパラメータの詳細については、Amazon RDS ドキュメントの「[Allocating memory for autovacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)」を参照してください。

## autovacuum パラメータの調整
<a name="autovacuum-tuning"></a>

ユーザーは、更新および削除オペレーションに応じて autovacuum パラメータを調整する必要が生じる場合があります。次のパラメータの設定を、テーブル、インスタンス、またはクラスターレベルで実行できます。

### クラスターまたはインスタンスレベル
<a name="autovacuum-cluster-instance"></a>

例として、継続的データ操作言語 (DML) オペレーションが予想される銀行データベースを見てみましょう。データベースの正常性を維持するには、Aurora のクラスターレベルと Amazon RDS のインスタンスレベルで autovacuum パラメータを調整し、リーダーにも同じパラメータグループを適用する必要があります。フェイルオーバーの場合は、同じパラメータを新しいライターに適用する必要があります。

### テーブルレベル
<a name="autovacuum-table"></a>

例えば、`orders` という 1 つのテーブルで継続的な DML オペレーションが予想されるフードデリバリー用のデータベースでは、次のコマンドを使用して `autovacuum_analyze_threshold` パラメータをテーブルレベルで調整することを検討する必要があります。

```
ALTER TABLE <table_name> SET (autovacuum_analyze_threshold = <threshold rows>)
```

### テーブルレベルで積極的な自動バキューム設定を使用する
<a name="autovacuum-table-aggressive"></a>

継続的な更新および削除オペレーションを行うサンプルの `orders` テーブルは、デフォルトの自動バキューム設定によりバキューム処理の候補となります。これにより、プランの生成が不正となり、クエリが遅くなります。肥大化の削除と統計の更新には、テーブルレベルの積極的な自動バキューム設定が必要です。

設定を決定するには、このテーブルで実行されているクエリの期間を追跡し、プランの変更につながる DML オペレーションの割合を特定します。`pg_stat_user_tables` ビューは、挿入、更新、削除オペレーションを追跡するのに役立ちます。

例:

`orders` テーブルの 5% が変更されるたびに、オプティマイザで不正なプランが生成されると仮定します。この場合、次のようにスケール係数のしきい値を 2% に変更する必要があります。

```
ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.02)
```

**ヒント**  
リソースの大量消費を避けるため、積極的な自動バキュームの設定では慎重に選択を行ってください。

詳細については次を参照してください:
+ [Amazon RDS for PostgreSQL 環境での autovacuum について](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/) (AWS ブログ記事)
+ [自動バキューム処理](https://www.postgresql.org/docs/17/runtime-config-autovacuum.html) (PostgreSQL ドキュメント)
+ Amazon [RDS と Amazon Aurora での PostgreSQL パラメータのチューニング](https://docs.aws.amazon.com//prescriptive-guidance/latest/tuning-postgresql-parameters/) (AWS 規範ガイダンス)

自動バキュームが効果的に機能することを確認するには、デッド行、ディスク使用量、および最後に自動バキュームまたは `ANALYZE` を実行した時間を定期的にモニタリングします。`pg_stat_all_tables` ビューには、各テーブル (`relname`) に関する情報と、テーブルにあるデッドタプルの数 (`n_dead_tup`) が表示されます。

各テーブル、特に頻繁に更新されるテーブルのデッドタプルの数をモニタリングすることで、自動バキュームプロセスがデッドタプルを定期的に削除しているかどうかを判断し、ディスク容量を再利用してパフォーマンスを向上させることができます。次のクエリを使用して、デッドタプルの数と、テーブルで最後に自動バキュームが実行された日時を確認できます。

```
SELECT
relname AS TableName,n_live_tup AS LiveTuples,n_dead_tup AS DeadTuples,
last_autovacuum AS Autovacuum,last_autoanalyze AS Autoanalyze_FROM 
pg_stat_user_tables;
```

## 利点と制限事項
<a name="autovacuum_limitations"></a>

自動バキュームには、次のような利点があります。
+ テーブルで肥大化が自動的に削除されます。
+ トランザクション ID の循環が防止されます。
+ データベース統計を最新の状態に保ちます。

機能制限:
+ クエリで並列処理を使用する場合、ワーカープロセスの数が自動バキュームの実行に十分ではない可能性があります。
+ 自動バキュームがピーク時に実行されると、リソースの使用率が増加する可能性があります。この問題を処理するには、パラメータを調整する必要があります。
+ テーブルページが別のセッションで占有されている場合、自動バキュームでそれらのページをスキップすることがあります。
+ 自動バキュームは一時テーブルにアクセスできません。