「なぜかPostgreSQLが重い…」その原因、オートバキュームが握っているかもよ？
やあ。データベースの運用、お疲れ様。
開発をしていると、クエリのチューニングやインデックスの設計に頭を悩ませることは多いよね。でも、PostgreSQLを長く運用していると、避けて通れない「影の主役」がいるんだ。それがオートバキューム（autovacuum）。
「設定はデフォルトのまま触ってない」とか「たまにプロセスが暴れて困る」なんて声もよく聞くけれど、こいつの仕組みを理解しておかないと、ある日突然、DBのパフォーマンスが崖から落ちるような事態に直面することになる。
今日は、現場の先輩として、オートバキュームの「中身」と「付き合い方」を少し深掘りしてみようか。
—
そもそも、なんでバキュームが必要なの？
PostgreSQLのMVCC（多版同時実行制御）という仕組みを覚えているかな？
PostgreSQLでは、データを更新したり削除したりしても、古いデータはすぐには消えない。「どこからも参照されなくなった古いデータ（デッドタプル）」として、ディスク上に残るんだ。
これを放置すると、テーブルは肥大化するし、インデックスのスキャン効率も落ちる。それを綺麗に掃除してくれるのがバキュームだ。さらに、プランナが適切な実行計画を立てるための「統計情報」も更新してくれる。
つまり、オートバキュームはDBの健康診断と大掃除を自動でやってくれる、無くてはならない清掃員なんだよ。
—
オートバキュームの「指揮官」と「作業員」
オートバキュームは、大きく分けて2つの役割で動いている。
1. Autovacuum Launcher (指揮官):
一定の間隔（`autovacuum_naptime`）で目覚め、「掃除が必要なテーブルはないか？」をチェックするプロセス。
2. Autovacuum Worker (作業員):
ランチャーから指令を受けて、実際に掃除を行うプロセス。同時に動ける数は `autovacuum_max_workers` で決まる。
ここで重要なのは、「作業員は並列で動けるけれど、一度に動ける数には制限がある」ということ。もし、掃除が必要なテーブルが山ほどあるのに、ワーカーの数が足りなければ、掃除は順番待ちになる。結果、デッドタプルが溜まりすぎてパフォーマンスが悪化するんだ。
—
現場でよく見る「詰まり」の正体
実務でよくあるのが、「大量更新したのに、オートバキュームが追いつかない」というケース。これには理由がある。
デフォルト設定だと、オートバキュームは「なるべくDBのパフォーマンスに影響を与えないように」控えめに働くようになっているんだ。具体的には、`autovacuum_vacuum_cost_limit` というパラメータで作業負荷を制限している。
もし君のDBで、「テーブルの更新頻度が激しいのに、掃除が全然進まない」と感じたら、以下のSQLで状況を確認してみてほしい。
— 今、どのテーブルがどれだけ不要なタプルを抱えているか確認するクエリ
SELECT
relname AS table_name,
n_dead_tup AS dead_tuples,
last_autovacuum,
last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;
`n_dead_tup` が数百万、数千万になっているテーブルがあれば、それは「掃除待ちの行列」ができている証拠だ。
—
現場の知恵：どうしても追いつかない時はどうする？
設定を全体的にガツンと引き上げるのは、あまりおすすめしない。サーバー全体の負荷が跳ね上がって、本番環境のレスポンスが悲鳴を上げることになるからね。
狙い撃ちで設定するのがプロのやり方だ。特定の大きなテーブルだけ、個別にバキュームの閾値を下げてやるんだ。
— 例：特定のテーブルだけ、掃除の条件を厳しくする
ALTER TABLE orders SET (
autovacuum_vacuum_scale_factor = 0.01, — 1%の更新で掃除開始
autovacuum_vacuum_cost_limit = 1000 — 少しだけ負荷を許容して頑張ってもらう
);
こうすることで、他の小さなテーブルには影響を与えず、問題のテーブルだけを重点的にケアできる。
—
最後に：完璧を目指しすぎないこと
最後に一つだけアドバイス。
オートバキュームは、「完璧に綺麗にする」ことよりも「膨張による崩壊を防ぐ」ことの方が重要だ。
時々、「ログにバキュームが遅いという警告が出るから、無理やりチューニングしたい」と相談してくる後輩がいるけど、無理な設定はCPUやI/Oを圧迫して、かえって本番クエリを遅くする。
まずは、`pg_stat_user_tables` で現状を把握し、ボトルネックになっているテーブルを見つける。そして、そのテーブルの特性（更新頻度やサイズ）に合わせて、少しずつパラメータを調整する。この「観察と微調整」こそが、DBエンジニアの醍醐味だよ。
DBは育てれば必ず応えてくれる。オートバキュームという強力な味方を、ぜひ上手く使いこなしてあげてくれ。
また何か困ったことがあったら、いつでも聞いてくれよな！
コメント