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

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

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

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

Autovacuum が推奨され、デフォルトで有効になっています。そのパラメータには以下が含まれます。

Autovacuum は、次のように、特定のしきい値式に基づいて処理するテーブルのリストを作成します。

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

Autovacuum メモリ関連のパラメータ

autovacuum_max_workers

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

maintenance_work_mem

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

autovacuum_work_mem

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

autovacuum メモリパラメータの詳細については、Amazon RDS ドキュメントの「autovacuum のメモリの割り当て」を参照してください。

autovacuum パラメータのチューニング

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

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

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

テーブルレベル

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

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

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

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

設定を決定するには、このテーブルで実行されているクエリの期間を追跡し、計画の変更につながる 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;

利点と制限事項

Autovacuum には次の利点があります。

制限: