「またautovacuumでヒイヒイ言ってるのか？」
PostgreSQLを触っていると、一度はぶつかる壁ですよね。パフォーマンスが急に落ちたり、ディスク容量がパンパンになったり。そんな時、デフォルト設定のまま放置していると、いつか必ず痛い目を見ます。
今日は、現場で僕がいつも「まずはここを見ろ」と言っている、autovacuumチューニングの勘所を共有します。教科書通りの説明は公式ドキュメントに任せて、ここでは「実戦でどう立ち回るか」に絞って話しますね。
—
なぜautovacuumが「悪者」扱いされるのか
よく「autovacuumが重いから止める」というエンジニアがいますが、それは大間違い。PostgreSQLのMVCC（多版同時実行制御）という仕組み上、古いデータを掃除しないとテーブルは肥大化し続け、インデックスもスカスカになり、クエリは遅くなる一方です。
つまり、「autovacuumは、あなたのデータベースを健康に保つための唯一の警備員」なんです。こいつが仕事をサボるか、あるいはやりすぎるかのバランスを取るのが、僕たちエンジニアの腕の見せ所です。
チューニングの基本は「回数を増やす」こと
デフォルトの設定だと、大規模なテーブルでは「いつまで経ってもVACUUMが始まらない」という現象が起きがちです。まずは、この2つのパラメータを意識してください。
- `autovacuum_vacuum_scale_factor`
- `autovacuum_analyze_scale_factor`
これらは「テーブルの何％が更新されたらVACUUM/ANALYZEを走らせるか」という閾値です。デフォルトは`0.2`（20%）。つまり、100万行あるテーブルなら、20万行変わるまで動かない。これじゃ遅すぎます。
実践的な設定例
僕が大規模テーブルに対してよくやる設定は、これです。
— テーブル単位で設定を上書きするのが鉄則！
ALTER TABLE orders SET (
autovacuum_vacuum_scale_factor = 0.01,
autovacuum_analyze_scale_factor = 0.005,
autovacuum_vacuum_threshold = 1000
);
こうすることで、「1%の変更でVACUUM、0.5%の変更でANALYZE」という、かなり敏感な設定に切り替わります。これで統計情報が常にフレッシュな状態に保たれ、プランナが賢い実行計画を選びやすくなります。
—
「重い」と感じた時の逃げ道：コスト制限
「敏感にすると、VACUUMが頻発してディスクI/Oが飽和するんじゃないか？」という心配、もっともです。その場合は、VACUUM自体の「仕事量」を制限してあげましょう。
— postgresql.conf またはテーブル単位の設定
autovacuum_vacuum_cost_limit = 1000 — 1回あたりのコスト上限を上げる
autovacuum_vacuum_cost_delay = 2ms — 休憩時間を短くする
ここで重要なのは、「一気に掃除させようとせず、細かく何度も動かす」という戦略です。`cost_limit`を適切に設定すれば、VACUUMがシステム全体を食いつぶすのを防ぎつつ、バックグラウンドで黙々と掃除を終わらせてくれます。
—
今、何が起きているのか？を可視化する
チューニングは勘だけじゃダメです。「今の状態」を知るために、僕はいつもこのクエリを叩いて確認しています。
SELECT
relname,
last_autovacuum,
last_autoanalyze,
n_dead_tup,
n_live_tup
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;
`n_dead_tup`（不要になった行数）が異常に増えていないか？ `last_autovacuum` があまりに古いままになっていないか？ これを定期的に眺めるだけで、システムの健康状態が手に取るようにわかるようになります。
—
最後に：先輩からのアドバイス
いいですか、チューニングに「唯一の正解」はありません。
アクセスが集中する夜間にガッツリ回すのか、日中の負荷を抑えるために小分けにするのか。それはあなたの環境のI/O性能と相談しながら決めるしかありません。
まずは、「デフォルト設定はあくまで汎用的なもの」という意識を持ってください。特定のテーブルで負荷が高いなら、そのテーブルに対して個別に設定を上書きする。この地道な積み重ねが、結局一番安定するシステムへの近道です。
迷ったら、まずは今の統計情報を確認するところから始めてみてください。それが、データベースエンジニアとしての第一歩ですからね。
何かあったらまた聞きに来てください。一緒にログを読み解きましょう！
コメント