Autovacuumという名の「静かなる守護者」と、どう付き合うべきか
PostgreSQLを長く運用していると、誰もが一度は「なぜかクエリが急に遅くなった」という壁にぶつかります。実行計画を見れば、Index Scanすべき場所で無情にもSeq Scanが選ばれている。原因は決まって「統計情報の鮮度不足」です。
PostgreSQLにおける統計情報の収集、いわゆる`ANALYZE`は、オプティマイザが最適なプランを選択するための羅針盤です。これをバックグラウンドで自律的に回し続ける`autovacuum`プロセスは、まさにデータベースの心臓部を支える静かなる守護者。しかし、この守護者との距離感を誤ると、パフォーマンスは途端に牙を剥きます。
今回は、このautovacuumの内部挙動を紐解きつつ、現場で泥臭くチューニングするための勘所を共有したいと思います。
—
内部アーキテクチャ：閾値という名の「潮目」
Autovacuumが`ANALYZE`を起動するトリガーは、実は非常にシンプルです。それは`autovacuum_analyze_threshold`と`autovacuum_analyze_scale_factor`という2つのパラメータによって決定されます。
計算式はこうですね。
「変更されたタプル数 > threshold + (テーブルの全タプル数 scale_factor)」
この条件式を満たした瞬間、autovacuumは重い腰を上げます。ここでエンジニアとして意識すべきは、「この計算式はあくまで目安である」という点です。
例えば、数千万件の巨大テーブルにおいて、`scale_factor`がデフォルト（0.1）のままだとどうなるか。数百万件の更新がないとANALYZEが走らないことになります。これでは統計情報が古すぎて、プランナは迷子になります。逆に、更新頻度の高い小さなマスタテーブルでは、頻繁なANALYZEがCPU負荷を押し上げることもある。
トラブルシューティング：統計情報の「罠」
「統計情報が更新されているはずなのに、なぜ実行計画が悪いのか？」
現場でよくあるのは、この問いです。これにはいくつかの落とし穴があります。
- データ分布の偏り（Skew）:
PostgreSQLの統計情報は、基本的にヒストグラムで管理されます。しかし、極端に偏ったデータ分布がある場合、デフォルトの`statistics_target`（100）では精度が足りません。特定のカラムでクエリの挙動がおかしいなら、まずそのカラムの統計ターゲットを上げてみるのが定石です。`ALTER TABLE … ALTER COLUMN … SET STATISTICS 500` のようにね。
- ANALYZEの競合:
autovacuumは一度に全テーブルを面倒見るわけではありません。`autovacuum_max_workers`で設定された数のプロセスが、優先度の高いテーブルから処理していきます。もし巨大なテーブルが統計情報の収集を独占していれば、他の小さなテーブルの更新が後回しにされ、結果として「統計情報の鮮度負け」が発生します。
現場で差がつくチューニングの鉄則
私がクライアントの現場でまず行うのは、「テーブルごとの個別最適化」です。グローバルな設定（`postgresql.conf`）だけで全体を制御しようとするのは、正直なところ無理があります。
1. 「動的な」テーブルには個別設定を
更新頻度が激しいテーブルについては、`ALTER TABLE … SET (autovacuum_analyze_scale_factor = 0.01)` のように、そのテーブル専用の閾値を設定してください。これにより、小さな変化でも素早く統計情報を反映させることができます。
2. コスト制限（Cost Limit）の調整
`autovacuum_vacuum_cost_limit`の設定が低すぎると、autovacuumは「慎重すぎて仕事が終わらない」状態になります。特に書き込みが多い環境では、このコスト制限を少し緩和して、バックグラウンドプロセスがしっかり仕事を完了できるように調整しましょう。
3. モニタリングをサボらない
`pg_stat_user_tables`を監視することは、エンジニアとしての最低限の嗜みです。`last_analyze`がいつ行われたか、どの程度データが変わったのか。この数字を追うだけで、システムの健康状態が驚くほど可視化されます。
—
最後に：完璧な自動化など存在しない
Autovacuumは確かに便利ですが、万能ではありません。究極的には、「どのデータがどのように変わるか」を一番理解しているのは、データベースではなく、設計したエンジニアであるべきです。
自動化に頼り切るのではなく、自らの手で統計情報の分布を確認し、必要とあらば手動で`ANALYZE`を打ち、実行計画の変化を楽しむ。そうした泥臭い試行錯誤の先にこそ、真の「ハイパフォーマンスなデータベース」があるのだと、私は信じています。
皆さんのPostgreSQLが、今日も健全に動き続けることを願っています。それでは、また。
コメント