【実務・中級編】オートバキュームランチャー – PostgreSQL

やあ。PostgreSQLを触り始めてしばらく経つと、必ずと言っていいほどぶつかる壁があるよね。そう、「バキューム（VACUUM）」だ。

「なぜか最近、DBが重い」「ログを見ると `autovacuum` が走っている」。そんな時、焦って設定をいじり回す前に、まずはPostgreSQLの心臓部で働いている「オートバキュームランチャー（Autovacuum Launcher）」が何をしているのか、正しく理解しておこう。

今日は、教科書には載っているようで載っていない、現場的な視点からこのプロセスの正体を暴いていくよ。

—

まず誤解を解いておこう。オートバキュームランチャー（autovacuum launcher）自身は、実際にデータをごそごそ掃除するわけじゃない。

こいつの役割はたった一つ。「監視」と「指示」だ。

1. 監視: 全データベースの統計情報をチェックする。
2. 判断: 「このテーブル、更新が激しすぎてゴミ（死んだタプル）が溜まりすぎじゃないか？」と閾値判定をする。
3. 指示: 基準を超えていたら、`autovacuum worker` という実働部隊をフォークして起動させる。

ランチャーは常に1つだけ存在し、バックグラウンドで黙々と「どのテーブルを掃除すべきか」を計算し続けている。いわば、現場の作業員に指示を出す「現場監督」のような存在だね。

PostgreSQLにはデフォルトで `autovacuum_vacuum_scale_factor` という設定がある。デフォルトは `0.2`（20%）。

「テーブルの20%が更新されたら掃除する」という仕組みなんだけど、これが数億行ある巨大テーブルだとどうなると思う？
20%の更新を待っていたら、とっくにストレージはゴミだらけでパンクするし、インデックスは肥大化してクエリは遅くなる。

現場で僕が最初に確認するのは、この設定だ。

— 現在の統計情報をざっくり確認するクエリ
SELECT relname, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;

このクエリで `n_dead_tup` がとんでもない数字になっていたら、ランチャーの設定がそのテーブルのサイズや更新頻度に追いついていない証拠だよ。

「オートバキュームが重いから止める」という判断をするエンジニアがいるけれど、それは「ブレーキが効かないからブレーキを外す」と言っているのと同じだ。絶対にやっちゃダメだぞ。

もしパフォーマンスに影響が出ているなら、「いつ、どれくらいの強さで掃除させるか」を制御するんだ。

特定の巨大テーブルだけ掃除のタイミングを早めたいなら、テーブル単位で設定を上書きできる。これが一番安全なチューニングだ。

ALTER TABLE orders SET (
autovacuum_vacuum_scale_factor = 0.05,
autovacuum_vacuum_threshold = 1000
);

これだけで、そのテーブルの掃除基準がグッと引き締まる。

複数のテーブルを同時に掃除したいなら、`autovacuum_max_workers` を増やすのも手だ（デフォルトは3）。ただし、ディスクI/Oがボトルネックになるから、SSDの性能と相談して慎重に決めること。

最後に一つ、一番大事なことを教えるよ。「オートバキュームのログをちゃんと取得する設定にしているか？」

`postgresql.conf` で `log_autovacuum_min_duration` を設定しておくと、実際にどれくらいの時間をかけて掃除が終わったかがログに出るようになる。

5秒以上かかったバキュームはログに残す
log_autovacuum_min_duration = 5000

これを見て、「あれ、このテーブル、毎日掃除に1時間もかかってるな」と気づくことが、データベースエンジニアとしての第一歩だ。統計情報が古いせいでプランナが変な実行計画を立てることもなくなるし、何よりDBが健康でいてくれることが一番の幸せだからね。

—

オートバキュームは、一見すると「勝手にDBを重くする厄介者」に見えるかもしれない。でも、それはPostgreSQLが君の代わりにゴミを片付けてくれている証なんだ。

仕組みを理解して、うまく付き合っていこう。また何か疑問があったら、いつでも聞きに来てくれ。君のDBライフが少しでも快適になることを祈っているよ。