19.10. Vacuum作業

PostgreSQL 18.0文書
		第19章サーバ設定
前へ	上へ	19.10. Vacuum作業	次へ

19.10. Vacuum作業 #

これらのパラメータは、バキューム処理の挙動を制御します。バキュームの目的と責任の詳細は24.1を参照してください。

19.10.1. 自動Vacuum作業 #

以下に示す設定は自動バキューム機能の動作を制御します。詳細は24.1.6を参照してください。これらの設定の多くは、テーブル単位で変更できることに注意してください。格納パラメータを参照してください。

autovacuum (boolean) #

サーバが自動バキュームランチャデーモンを実行すべきかどうかを管理します。デフォルトでは有効です。しかし自動バキュームを作動させるためにはtrack_countsも有効でなければなりません。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、テーブル格納パラメータを変更することにより、自動バキュームは個々のテーブルに対して無効にできます。

このパラメータが無効であったとしてもシステムは、トランザクションIDの周回を防止する必要があれば、自動バキュームプロセスを起動することに注意してください。詳細は24.1.5を参照してください。

autovacuum_worker_slots (integer) #

自動バキュームワーカープロセス用に予約するバックエンドのスロット数を指定します。デフォルトは通常16スロットですが、カーネル設定でサポートされない場合（initdb中に判定します）、それより少なくなる可能性があります。このパラメータはサーバ起動時のみ設定可能です。

この値を変更する場合は、autovacuum_max_workersを調整することも考慮してください。

autovacuum_max_workers (integer) #

同時に実行することができる自動バキュームプロセス（自動バキュームランチャ以外）の最大数を指定します。デフォルトは3です。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。

autovacuum_worker_slotsよりも大きい値を設定しても効果はありません。これは、自動バキュームワーカーがこの設定によって確立されたスロットのプールから取得されるためです。

autovacuum_naptime (integer) #

あるデータベースについて実行される自動バキュームデーモンの最小遅延を指定します。それぞれの周期で、デーモンはそのデータベースを試験し、そしてそのデータベース内のテーブルで必要性が認められると、VACUUMおよびANALYZEコマンドを発行します。この値が単位なしで指定された場合は、秒単位であるとみなします。デフォルトは1分（1min）です。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。

autovacuum_vacuum_threshold (integer) #

ある任意のテーブルでVACUUMが起動されるのに必要な更新もしくは削除されたタプルの最小数を指定します。デフォルトは50タプルです。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_vacuum_insert_threshold (integer) #

ある任意のテーブルでVACUUMが起動されるのに必要な挿入タプル数を設定します。デフォルトは1000タプルです。 -1が指定されると、自動バキュームが挿入タプル数に基づいてVACUUM操作を引き起こすことはなくなります。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_analyze_threshold (integer) #

ある任意のテーブルでANALYZEが起動されるのに必要な、挿入、更新、もしくは削除されたタプルの最小数を指定します。デフォルトは50タプルです。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_vacuum_scale_factor (floating point) #

VACUUMを起動するかどうか決定するときに、autovacuum_vacuum_thresholdに追加するテーブルサイズの割合を指定します。デフォルトは0.2（テーブルサイズの20%）です。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_vacuum_insert_scale_factor (floating point) #

VACUUMを起動するかどうか決めるときに、autovacuum_vacuum_insert_thresholdに追加するテーブルの未凍結なページの割合を指定します。デフォルトは0.2（テーブルで未凍結なページの20%）です。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_analyze_scale_factor (floating point) #

ANALYZEを起動するかどうか決めるときに、autovacuum_analyze_thresholdに追加するテーブルサイズの割合を指定します。デフォルトは0.1（テーブルサイズの10%）です。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_vacuum_max_threshold (integer) #

ある任意のテーブルでVACUUMが起動されるのに必要な更新または削除されたタプルの最大数、つまりautovacuum_vacuum_thresholdとautovacuum_vacuum_scale_factorで計算される値の上限値を指定します。デフォルトは1億タプルです。 -1を指定すると、自動バキュームは、VACUUM操作を起動する更新または削除されたタプルの最大数を強制しません。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_freeze_max_age (integer) #

トランザクションID周回を防ぐためにVACUUM操作が強制される前までにテーブルのpg_class.relfrozenxidフィールドが到達できる（トランザクションにおける）最大の年代を指定します。自動バキュームが無効であった時でも、システムは周回を防ぐために自動バキューム子プロセスを起動することに注意してください。

バキューム処理は同時にpg_xactサブディレクトリから古いファイルの削除を許可します。これが、比較的低い2億トランザクションがデフォルトである理由です。このパラメータはサーバ起動時にのみ設定可能です。しかし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルで減らすことができます。詳細は24.1.5を参照してください。

autovacuum_multixact_freeze_max_age (integer) #

トランザクションID周回を防ぐためにVACUUM操作が強制される前までにテーブルのpg_class.relminmxidフィールドが到達できる（マルチトランザクションにおける）最大の年代を指定します。自動バキュームが無効であった時でも、システムは周回を防ぐために自動バキューム子プロセスを起動することに注意してください。

マルチトランザクションのバキューム処理は同時にpg_multixact/membersとpg_multixact/offsetsサブディレクトリから古いファイルの削除を許可します。これが、比較的低い4億トランザクションがデフォルトである理由です。このパラメータはサーバ起動時にのみ設定可能です。しかし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルで減らすことができます。詳細は24.1.5.1を参照してください。

autovacuum_vacuum_cost_delay (floating point) #

自動VACUUM操作に使用されるコスト遅延値を指定します。 -1が指定されると、通常のvacuum_cost_delayの値が使用されます。この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。デフォルト値は2ミリ秒です。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

autovacuum_vacuum_cost_limit (integer) #

自動VACUUM操作に使用されるコスト限界値を指定します。（デフォルトの）-1が指定されると、通常のvacuum_cost_limitの値が使用されます。実行中の自動バキュームワーカーが複数存在する場合、この値はすべてのワーカーに比例分配されることに注意してください。したがって各ワーカーの上限の合計がこの変数の値を超えることはありません。このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

19.10.2. コストに基づくVacuum遅延 #

VACUUM および ANALYZE コマンドの実行中、実行される各種I/O操作の予測コストを追跡し続ける内部カウンタをシステムが保守します。累積されたコストが（vacuum_cost_limitで指定された）限度に達すると、操作を実行しているプロセスはvacuum_cost_delayで指定されたちょっとの間スリープします。その後、カウンタをリセットし、実行を継続します。

この機能の目的は、同時に実行されているデータベースの活動に対するこれらコマンドによるI/Oへの影響を、管理者が軽減できるようにすることです。 VACUUM および ANALYZEの様な保守用コマンドが即座に終了することが重要ではない事態が数多くあります。しかし、他のデータベースの操作を行うに当たって、これらのコマンドがシステムの能力に多大な阻害を与えないことは通常とても重要です。コストに基づいたvacuum遅延はこれを実現するための方法を管理者に提供します。

手動で実行したVACUUMコマンドについては、デフォルトでこの機能は無効になっています。有効にするには、vacuum_cost_delay変数をゼロでない値に設定します。

vacuum_cost_delay (floating point) #

コストの上限を越えた場合に、プロセスがスリープする時間の長さです。この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。デフォルトの値は0で、コストに基づいたvacuum遅延機能を無効にします。正の整数はコストに基づいたvacuumを有効にします。

コストに基づいたバキューム処理を使用する場合、vacuum_cost_delayの適切な値は通常かなり小さくなり、おそらく1ミリ秒以下になります。バキュームによるリソース消費の調整は、他のバキュームのコストパラメータを変更して行うことが最善です。 vacuum_cost_delayを1ミリ秒以下に設定することは可能ですが、そうした遅延は古いプラットフォームでは正確には計測されないかも知れません。そうしたプラットフォームでは、VACUUMのリソース消費制限を1ミリ秒のときに得られる値以上にするには、他のVACUUMコストパラメータの変更が必要となるでしょう。とは言うものの、使用するプラットフォームで常に計測できる範囲でvacuum_cost_delayをできるだけ小さくするようにしてください。大きな遅延は助けになりません。

vacuum_cost_page_hit (integer) #

共有バッファキャッシュにあるバッファをバキュームするための推定コストです。これは、バッファプールのロック、共有ハッシュテーブルの検索、およびページ内容をスキャンするためのコストを示します。デフォルトの値は1です。

vacuum_cost_page_miss (integer) #

ディスクから読み込まれなければならないバッファをバキュームするための推定コストです。これは、バッファプールロックの試み、共有ハッシュテーブルの参照、ディスクから目的ブロックの読み込み、そしてその内容をスキャンするためのコストを示します。デフォルトの値は2です。

vacuum_cost_page_dirty (integer) #

以前掃除されたブロックをバキュームで変更するときに必要な推定コストです。これは、ダーティブロックを再度ディスクにフラッシュするのに必要な追加のI/Oを表します。デフォルトの値は20です。

vacuum_cost_limit (integer) #

これは、バキューム処理をvacuum_cost_delayの間スリープさせるための累積コストです。デフォルトの値は200です。

注記

重要なロックを保有し可能なかぎり早急に完了しなければならないある種の操作があります。コストに基づいたvacuum遅延はこの様な操作では起こりません。したがって、コストの累計が指定された限度をかなり高く超える可能性があります。このような場合無駄な長い遅延を防止するため、実際の遅延はvacuum_cost_delay * 4 を上限として、以下のように計算されます。 vacuum_cost_delay * accumulated_balance / vacuum_cost_limit

19.10.3. デフォルトの動作 #

vacuum_truncate (boolean) #: テーブルの最後にある空のページを切り捨てようとするバキュームの機能を有効または無効にします。デフォルト値はtrueです。 trueに設定すると、VACUUMと自動バキュームが切り捨てを行い、切り捨てられたページのディスク容量がオペレーティングシステムに返されます。切り捨てにはテーブルのACCESS EXCLUSIVEロックが必要であることに注意してください。 VACUUMのTRUNCATEパラメータが指定されている場合、このパラメータの値を上書きします。この設定はテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。

19.10.4. 凍結処理 #

トランザクションIDが周回した後でも正確さを維持するために、PostgreSQLは十分に古い行を凍結済みとして印付けます。これらの行はすべてのユーザに表示されます。他のトランザクションでは、挿入したXIDを調べて可視性を判断する必要はありません。 VACUUMには、行を凍結状態として印付ける責任があります。次の設定はVACUUMの凍結動作を制御します。これらの設定は、システムのXID消費率と主要なワークロードのデータ参照パターンに基づいて調整する必要があります。トランザクションIDの周回とこれらのパラメータの調整の詳細については、24.1.5を参照してください。

vacuum_freeze_table_age (integer) #

テーブルのpg_class.relfrozenxidフィールドがこの設定で指定した年代に達すると、VACUUMは積極的なテーブルスキャンを行います。積極的なスキャンは、無効タプルを含む可能性のあるページだけではなく、凍結されていないXIDあるいはMXIDを含むすべてのページを読む点で通常のVACUUMとは異なります。デフォルトは1.5億トランザクションです。ユーザはこの値をゼロから20億までの任意の値に設定することができますが、周回問題対策の自動バキュームがテーブルに対して起動する前に定期的な手動VACUUMが実行する機会を持つように、VACUUMは警告することなく実際の値をautovacuum_freeze_max_ageの95%に制限します。詳細は24.1.5を参照してください。

vacuum_freeze_min_age (integer) #

VACUUMが、古いXIDを持つページの凍結を行うかどうかを決定する、カットオフ年代を（トランザクション単位で）指定します。デフォルトは5千万トランザクションです。ユーザはこの値をゼロから10億までの間で任意の値に設定することができますが、VACUUMは警告することなく実際の値をautovacuum_freeze_max_ageの半分の値まで制限します。このため、強制的な自動バキュームの間隔が不合理に短くなることはありません。詳細は24.1.5を参照してください。

vacuum_failsafe_age (integer) #

VACUUMがシステム全体に渡るトランザクションID周回障害を避けるために異例の措置を取るようになる、テーブルのpg_class.relfrozenxidフィールドが到達する最大の（トランザクション数単位での）年代を指定します。これはVACUUMの最後の手段となる戦略です。この安全機構は典型的には、トランザクションID周回を防ぐための自動バキュームがすでに走っているときに起動されます。しかし、すべてのVACUUMの実行中にこの安全機構が起動する可能性があります。

この安全機構が起動すると、すべての有効なコストに基づく遅延はもはや適用されず、（インデックスのバキュームのような）必須ではない保守タスクは迂回されます。使用中のバッファアクセスストラテジは無効になり、その結果VACUUMは共有バッファのすべてを自由に使用することになります。

デフォルトは16億トランザクションです。ユーザはこの値をゼロから21億までの間で設定できますが、VACUUMは警告することなく実際の値をautovacuum_freeze_max_ageの105%よりも小さくならないように調整します。

vacuum_multixact_freeze_table_age (integer) #

pg_class.relminmxidフィールドがこの設定値で指定した年代に達すると、VACUUMはテーブルの積極的なスキャンを行います。積極的なスキャンは、無効タプルを含む可能性のあるページだけではなく、凍結されていないXIDあるいはMXIDを含むすべてのページを読む点で通常のVACUUMとは異なります。デフォルトは1億5千万トランザクションです。ユーザはゼロから20億まで任意の値を設定できますが、テーブルに対して周回防止処理が起動される前に定期的な手動VACUUMが走ることができるように、VACUUMは警告することなく実際の値をautovacuum_multixact_freeze_max_ageの95%まで制限します。詳細は24.1.5.1を参照してください。

vacuum_multixact_freeze_min_age (integer) #

VACUUMが、古いマルチトランザクションIDを持つページの凍結を行うかどうかを決定する、カットオフ年代を（マルチトランザクション単位で）指定します。デフォルトは500万マルチトランザクションです。ユーザはゼロから10億まで任意の値を設定できますが、強制的な自動バキュームの間隔が短くなり過ぎないように、VACUUMは警告することなく実際の値をautovacuum_multixact_freeze_max_ageの半分の値に制限します。詳細は24.1.5.1を参照してください。

vacuum_multixact_failsafe_age (integer) #

VACUUMがシステム全体マルチトランザクションID周回障害を避けるために異例の措置を取るようになる、テーブルのpg_class.relminmxidフィールドが到達する最大の（マルチトランザクション数単位での）年代を指定します。これはVACUUM最後の手段となる戦略です。この安全機構は典型的には、マルチトランザクションID周回を防ぐための自動バキュームがすでに走っているときに起動されます。しかし、すべてのVACUUMの実行中にこの安全機構が起動する可能性があります。

この安全機構が起動すると、すべての有効なコストに基づく遅延はもはや適用されず、（インデックスのバキュームのような）必須ではない保守タスクは迂回されます。

デフォルトは16億マルチトランザクションです。ユーザはこの値をゼロから21億までの間で設定できますが、VACUUMは警告することなく実際の値をautovacuum_multixact_freeze_max_ageの105%よりも小さくならないように調整します。

vacuum_max_eager_freeze_failure_rate (floating point) #

熱心なスキャンを無効にする前に、VACUUMがスキャンした時に可視性マップで全凍結と設定することに失敗するページの最大数（そのリレーション内の全ページ数に対する割合）を指定します。値が0の場合、熱心なスキャンは完全に無効になります。デフォルトは0.03（3%）です。

熱心なスキャンを有効にすると、凍結の失敗のみがカウントされ、凍結の成功はカウントされないことに注意してください。凍結に成功するページは、内部的には、そのリレーション内の全可視ではあるが全凍結ではないページの20%に制限されます。凍結に成功するページを制限すると、複数の通常のバキューム処理でオーバーヘッドを分散でき、次の積極的バキュームの前に再度修正されたページに対する熱心な凍結処理が無駄になるという潜在的な欠点を抑えることができます。

このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。ただし、この設定は対応するテーブル格納パラメータの変更により、それぞれのテーブルに対して上書きすることができます。バキュームの凍結動作の詳細については、24.1.5を参照してください。

前へ	上へ	次へ
19.9. 実行時統計情報	ホーム	19.11. クライアント接続デフォルト