その`maintenance_work_mem`、本当にデフォルトのままでいいのか？
PostgreSQLのチューニングにおいて、`shared_buffers`や`work_mem`に注目するのは定石だ。だが、現場で長年PostgreSQLと向き合っていると、意外と見落とされがちなのに、システムの「寿命」を決定づけるパラメータがあることに気づく。
そう、`maintenance_work_mem`だ。
多くのサーバーで「とりあえず64MB」や「標準のまま」にされているこの値。しかし、大規模なデータセットを扱う環境で、この値を甘く見ていると、深夜のメンテナンスウィンドウがいつまで経っても終わらない、あるいはVACUUMが追いつかずにテーブルが肥大化し続けるという「悪夢」を見ることになる。
今日は、なぜこのパラメータが重要なのか、内部で何が起きているのかを深掘りしてみよう。
—
メンテナンス処理の「作業場」としての役割
`maintenance_work_mem`は、その名の通り、DBのメンテナンス操作――`VACUUM`、`CREATE INDEX`、`ALTER TABLE ADD FOREIGN KEY`といった重い処理が実行される際の、一時的な作業用メモリだ。
ここが賢いのは、このメモリが「共有」ではなく「セッション単位」で確保される点だ。例えば、`autovacuum_work_mem`が設定されていない場合、オートバキュームの各ワーカーもこの設定値を使用する。
内部で何が起きているのか：ソートとインデックス構築
特に重要なのが、インデックス構築やVACUUM時の「TID（タプル識別子）のソート」だ。
例えば、B-Treeインデックスを新規作成する際、PostgreSQLはテーブルをスキャンし、キーとTIDをメモリ上の配列に詰め込む。もしメモリが足りなければどうなるか？ 答えは明白だ。外部ソート（ディスクI/O）が発生する。
想像してみてほしい。数億行あるテーブルのインデックスを再構築する際、メモリに収まりきらずに一時ファイル（temp file）への書き込みが発生した瞬間のパフォーマンス低下を。ディスクI/Oはメモリより数桁遅い。このメモリをケチることは、メンテナンス時間を物理的な限界まで引き延ばすことに他ならない。
—
パフォーマンストラブルシューティングの勘所
僕が現場でよく見る「アンチパターン」は、この値を極端に小さく設定したまま、巨大なテーブルに対してインデックスを再構築しようとするケースだ。
1. 「いつまで経っても終わらない」という叫び
インデックス構築中の `pg_stat_activity` を覗いてみてほしい。もし `wait_event_type` に `IO` が頻出しているなら、それはメモリ不足のサインかもしれない。特に `CREATE INDEX CONCURRENTLY` を使っている場合、時間がかかることは承知の上だろうが、`maintenance_work_mem` を増やすだけで、処理時間が半分以下になることも珍しくない。
2. VACUUMの「追い抜き」問題
高負荷な書き込みがあるシステムで、VACUUMが追いつかないという相談を受けることがある。ここでも `maintenance_work_mem` が鍵を握る。
メモリが小さすぎると、VACUUMは何度もディスクをスキャンし直してTIDを処理することになり、効率が極端に落ちる。メモリを十分に与えれば、一度のスキャンでより多くの dead tuple を処理でき、autovacuum の負荷を下げることができるんだ。
—
チューニングの目安：どこまで盛るべきか
では、どれくらいの設定が適切か？
もちろん、「サーバーのメモリ次第」という身も蓋もない結論になるが、経験則として言えることがある。
- 物理メモリに余裕があるなら： 1GB〜2GB程度まで上げてもいい。特にインデックス構築が頻発する環境や、巨大なテーブルを扱うなら、ここは贅沢に使っていい領域だ。
- オートバキュームとの兼ね合い： もしオートバキュームがメモリを食いすぎてOSがOOM Killerを起動させるのが怖いなら、`autovacuum_work_mem` を別途設定し、こちらは控えめにしつつ、手動のメンテナンスコマンド実行時だけセッション単位で増やすというテクニックも有効だ。
— セッションごとに一時的に増やすという戦略
SET maintenance_work_mem = ‘2GB’;
CREATE INDEX CONCURRENTLY …;
—
最後に：完璧な設定値はない
PostgreSQLのチューニングに「銀の弾丸」は存在しない。
インデックス作成の速度を優先するのか、それとも同時実行される他のクエリのためにメモリを温存するのか。それはシステムごとの性格に依存する。
ただ一つ言えるのは、`maintenance_work_mem` は「普段は見えないけれど、いざという時にシステムの安定性を支える縁の下の力持ち」だということだ。
あなたのDBが重いメンテナンスに苦しんでいるなら、まずはこの値を少しだけ増やして、`EXPLAIN ANALYZE` の結果や `pg_stat_database` の統計情報を眺めてみてほしい。きっと、PostgreSQLが「もっと早く動けたのに！」と囁いてくれるはずだ。
さて、今日はここまで。また深い沼でお会いしよう。
コメント