PostgreSQLの「勘所」：effective_cache_sizeは魔法の杖か、それとも諸刃の剣か
PostgreSQLのチューニングにおいて、`effective_cache_size`ほど誤解を受けやすく、かつ奥が深いパラメータも珍しい。
PostgreSQLを触り始めて数年、「とりあえず物理メモリの75%くらいにしておけばいいんでしょ？」というアドバイスを鵜呑みにしたことはないだろうか。あるいは、本番環境でなぜかプランナが不可解なシーケンシャルスキャンを選択し、その原因を深掘りする過程でこの設定値に辿り着いた経験はないだろうか。
今日は、この「一見地味だが極めて重要な設定値」が、PostgreSQLのクエリオプティマイザの脳内で一体何をしているのか、少しマニアックな視点で解き明かしていきたいと思う。
そもそも、effective_cache_sizeは「メモリ」ではない
まず大前提として共有しておきたいのは、`effective_cache_size`はメモリ領域を確保するものではないということだ。`shared_buffers`がPostgreSQLの共有メモリ領域という「実体」を定義するのに対し、`effective_cache_size`はあくまでプランナへの「見積もり（ヒント）」に過ぎない。
具体的には、クエリの実行時にOSのページキャッシュに乗っているであろうデータ量を見積もらせるための値だ。プランナは、この値を基に「インデックススキャンとシーケンシャルスキャンのどちらが安上がりか」を計算する。
なぜプランナは「キャッシュに乗っている」と仮定したいのか
内部的な話に少し踏み込むと、PostgreSQLのコストモデルにおいて、インデックススキャンのコスト計算には「ランダムI/O」のコストが大きく関与する。
もしデータがOSのキャッシュ上に存在していれば、ランダムI/Oのペナルティは無視できるレベルまで下がる。つまり、`effective_cache_size`を適切に設定することで、プランナに対して「メモリ上に乗っている可能性が高いから、インデックススキャンを積極的に選んでくれ」と示唆できるわけだ。
逆に、この値が実態より極端に小さいと、プランナは「インデックススキャンはディスクI/Oが激しすぎて遅い」と判断し、結果として不要なシーケンシャルスキャンが選択されるという、パフォーマンス上の「事故」が起こる。
チューニングの現場で陥る「見積もりの乖離」
現場でトラブルシューティングをしていると、この値を「物理メモリの合計値」と同一視してしまうケースによく遭遇する。しかし、これは危険な思い込みだ。
以下の要素を考慮しないと、プランナは楽観的な計算結果を出し、実行計画を誤る。
- OSや他のプロセスが消費するメモリ: PostgreSQL以外のミドルウェアやOS自体がキャッシュを使うことを忘れてはならない。
- 共有メモリ（shared_buffers）との重複: `effective_cache_size`は「OSのページキャッシュ」を意図しているが、PostgreSQLは`shared_buffers`もキャッシュとして利用する。ここをどう評価するかは議論が分かれるが、基本的には「PostgreSQLが使えるメモリの総量」として捉えるのが現実的だ。
- ワーキングセットのサイズ: そもそも、頻繁にアクセスされるデータ（ワーキングセット）が物理メモリに収まっているかどうか。もしワーキングセットが物理メモリの10倍あるなら、`effective_cache_size`をいくら大きくしても、それは「空虚な期待」に過ぎない。
熟練エンジニアはどう向き合うべきか
僕がチューニングの現場でよくやる手法は、「実測値からのバック計算」だ。
`pg_buffercache`拡張を使って、実際に`shared_buffers`に何が乗っているのかを可視化し、OSの`free`コマンド等でキャッシュの増減を追う。その上で、`EXPLAIN ANALYZE`のコスト見積もりと、実際の実行時間（特にディスクI/Oによる待機時間）を突き合わせる。
プランナがインデックススキャンを選択しているのに、実際にはディスクI/Oで詰まっているなら、`effective_cache_size`が過大評価されている可能性が高い。逆に、シーケンシャルスキャンがボトルネックになっているなら、もう少しプランナを背中押ししてやってもいいかもしれない。
結論：パラメータは対話の手段である
`effective_cache_size`は、単なる設定値ではない。これは、あなたが運用しているデータベースの「データアクセス特性」をプランナに伝えるための、極めて重要な「対話の手段」だ。
「とりあえずこの値」という定石は存在しない。データ量、アクセスパターン、そしてOSのメモリ管理との相性。これらを俯瞰し、実行計画という「プランナの回答」を読み解く力こそが、我々エンジニアの腕の見せ所なのだ。
あなたのシステムのクエリが、今日も効率的なプランで実行されることを願っている。もし実行計画が期待通り動かないときは、この「キャッシュの幻影」を疑ってみてほしい。案外、真実はそこにあるはずだ。
コメント