VACUUMの「さじ加減」：PostgreSQLのインデックス肥大化と戦うための最適解
PostgreSQLと付き合いが長くなればなるほど、ある事実に気づくはずです。そう、「VACUUMは単なるゴミ掃除ではない」という事実です。
特に大規模なシステムを運用していると、インデックスの肥大化（Index Bloat）という怪物に頭を悩ませることになります。ストレージを圧迫するだけならまだしも、クエリのレスポンスタイムが徐々に劣化していくあの感覚。あれを「仕様です」と言い切るわけにはいきませんよね。
今日は、Autovacuumのパラメータを単なる「デフォルトからの変更」ではなく、アーキテクチャの文脈でどう捉えるべきか、深掘りしてみましょう。
—
MVCCと「可視性マップ」のダンス
PostgreSQLのMVCC（多版同時実行制御）において、VACUUMの役割はデッドタプルの物理的な削除だけではありません。もっと重要なのは、「可視性マップ（Visibility Map）」の更新です。
インデックスオンリースキャン（Index Only Scan）を狙う際、PostgreSQLは可視性マップを参照して、そのページ内の全タプルがすべてのトランザクションから可視かどうかを確認します。もしVACUUMが遅れて可視性マップが更新されないと、わざわざヒープページまでI/Oを発生させにいくことになり、インデックスオンリースキャンの恩恵が霧散します。
つまり、VACUUMをチューニングすることは、単なる領域回収ではなく、「クエリ最適化プランナーに正しい道筋を与えること」と同義なのです。
—
Autovacuumチューニング：なぜ「標準」では足りないのか
Autovacuumのパラメータ調整で、多くの人が `autovacuum_vacuum_scale_factor` をいじることに終始しますが、大規模テーブルにおいてはこれが諸刃の剣になります。
- scale_factorの罠: 例えばデフォルトの0.2（20%）をそのままにしておくと、1億行あるテーブルでは2,000万行更新されるまでVACUUMが走りません。これではインデックスの肥大化を抑えるには手遅れです。
- cost_limitのバランス: `autovacuum_vacuum_cost_limit` を低く見積もりすぎると、VACUUMが完了する前に次の更新がやってくる「いたちごっこ」になります。一方で高くしすぎると、通常のクエリがI/O待ちを強いられます。
実践的なチューニングの哲学
私が現場でよく使うアプローチは、「大物テーブルには個別の設定を充てる」ことです。`ALTER TABLE … SET (autovacuum_vacuum_scale_factor = 0.01)` のように、テーブルのサイズに合わせてこの値を小さく設定します。
また、インデックスの肥大化に悩まされているなら、`autovacuum_vacuum_cost_limit` を引き上げると同時に、`autovacuum_vacuum_cost_delay` を調整してみてください。高スループットなシステムでは、VACUUMを「細く、長く」動かすよりも、「短く、集中して」終わらせる方が、ページキャッシュの汚染を最小限に抑えられるケースが多いのです。
—
インデックス肥大化は「戦う」ものか「受け入れる」ものか
正直に言えば、PostgreSQLでインデックスの肥大化を「ゼロ」にすることはできません。これはMVCCの代償です。
しかし、「制御可能な範囲に収めること」はできます。私が監視しているのは、`pgstattuple` 拡張を使った実際の肥大率です。
— 肥大率を確認する定石
SELECT FROM pgstatindex(‘target_index_name’);
ここで `avg_leaf_density` が低い場合、それはデータがページ内にスカスカに詰まっているサインです。もしAutovacuumを適切にチューニングしても改善しないなら、それは `FILLFACTOR` の見直し時かもしれません。インデックスの更新頻度が高いテーブルに対して `FILLFACTOR` を少し下げておくだけで、ページ分割（Page Split）の頻度が劇的に減り、結果としてインデックスの寿命を延ばすことができます。
—
最後に：エンジニアとしての嗅覚
PostgreSQLのチューニングにおいて、魔法のような「万能設定」は存在しません。あるのは、ワークロードという名の「生き物」に合わせた調整の繰り返しだけです。
「なぜこのテーブルだけ肥大化が早いのか？」
「このクエリは本当にインデックスオンリースキャンできているのか？」
こういった問いを常に持ち続けること。そして、ログを見てAutovacuumが実際にどの程度の頻度で、どの程度のコストで走っているのかを肌感覚で理解すること。それが、世界最高峰のデータベースエンジニアへの近道だと私は信じています。
皆さんのデータベースの「呼吸」が、今日も健やかであることを祈っています。もし特定のワークロードで詰まっているなら、ぜひコメントやTwitterで議論しましょう。現場の苦労話こそ、最高の教科書ですから。
コメント