悪魔は細部に宿る：PostgreSQLの `work_mem` との終わりなき戦い
PostgreSQLのパフォーマンスチューニングにおいて、`work_mem`ほどエンジニアの腕が試されるパラメータはない。公式ドキュメントには「ソートやハッシュ操作に使われるメモリ」と短く記されているが、実運用ではこれがいかに曲者であるかは、現場で血の汗を流した者なら誰もが知っているはずだ。
「とりあえず大きくしておけば速くなるだろう」という安易な設定が、数時間後にはOOM Killerを誘発し、データベースを再起動へ追い込む。逆に保守的すぎれば、I/O待ちの嵐に晒される。この繊細なバランスをどう制御するか。今日は、その深淵を少し覗いてみよう。
—
「メモリ内」という聖域を守るために
`work_mem`の本質は、PostgreSQLがクエリ処理の過程で、物理ディスクへの退避（いわゆる「外部ソート」や「ディスク上のハッシュ」）をどれだけ回避できるかという点にある。
内部アーキテクチャの観点で見れば、`work_mem`は「操作単位」で割り当てられる。ここが最も重要な罠だ。もし`work_mem`を1GBに設定し、1つのクエリの中で10個のソート処理が並行して走れば、単純計算で10GBのメモリが食いつぶされる。コネクション数を `max_connections` で制限していても、この「乗数」を考慮しなければ、サーバーはあっという間にスワップアウトの泥沼に沈む。
パフォーマンストラブルシューティング：その「遅延」の正体を見極める
クエリが遅いとき、`EXPLAIN ANALYZE` を叩くのは当然の儀式だ。しかし、そこに現れる `Disk: 1234kB` という表示を、ただの「少し遅い」と見過ごしていないだろうか。
- Disk Merge: ソートが `work_mem` に収まりきらず、テンポラリファイルが生成されている証拠だ。
- Hash Batches: ハッシュ結合でメモリが不足し、データを分割して処理している。これはCPUコストだけでなく、ディスクI/Oのレイテンシを直撃する。
もし `EXPLAIN ANALYZE` でこれらが見えたなら、まずは `work_mem` を疑うのが定石だ。ただし、むやみに増やす前に、実行計画自体が最適かを確認してほしい。インデックスが効いていないフルスキャンが原因なら、メモリをいくら積んでも焼け石に水だからだ。
「動的設定」という賢い選択
熟練のエンジニアは、グローバルな `postgresql.conf` で `work_mem` を決めることに固執しない。特定の重いバッチ処理や、複雑な集計クエリだけがメモリを大量消費するケースは多々ある。
— 重い集計クエリの直前にだけ引き上げる
SET LOCAL work_mem = ’64MB’;
SELECT … FROM …;
このように、コネクション単位で必要なときだけメモリを開放する。これが大規模システムを運用する上での「美学」だと私は考えている。最近のバージョンでは `effective_io_concurrency` や `maintenance_work_mem` との兼ね合いも重要だが、まずは `work_mem` がクエリのライフサイクル全体にどう影響するか、その依存関係を可視化することから始めてみてほしい。
最後に：数値に踊らされないために
チューニングの究極は「設定値を決めること」ではなく、「なぜその数値が必要なのか」を言語化できるようになることだ。
`work_mem` は銀の弾丸ではない。むしろ、私たちの無知を鋭く突いてくる試験官のようなものだ。OSのメモリ状況、クエリの同時実行数、そしてデータのカーディナリティ。これらすべてのパズルが噛み合ったとき、PostgreSQLは期待以上のパフォーマンスを返してくれる。
皆さんのデータベースが、今日も健やかに、そして軽やかにクエリを処理してくれることを願っている。もし行き詰まったら、もう一度、`EXPLAIN ANALYZE` の結果と、サーバーの `vmstat` をじっくりと眺めてみてほしい。答えは必ず、そのデータの中に眠っているはずだ。
コメント