テーブルのバキューム処理と分析の自動実行

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

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

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

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

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

自動バキュームのメモリ関連パラメータ

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」を参照してください。

autovacuum パラメータの調整

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

クラスターまたはインスタンスレベル

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

テーブルレベル

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

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

テーブルレベルで積極的な自動バキューム設定を使用する

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

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

例:

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

ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.02)

詳細については次を参照してください:

自動バキュームが効果的に機能することを確認するには、デッド行、ディスク使用量、および最後に自動バキュームまたは 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;

利点と制限事項

自動バキュームには、次のような利点があります。

制限: