PostgreSQLの「心臓部」、shared_buffersとどう向き合うべきか？
現場でPostgreSQLをいじっていると、一度は必ずぶち当たる壁がある。「クエリが遅い」。そのとき、多くのエンジニアが真っ先にパラメータチューニングの画面を開くわけだけど、そこで必ず目にするのが `shared_buffers` だよね。
正直に言うよ。この設定一つで、サーバーの性能がガラッと変わることもあれば、逆に設定をミスって泥沼にハマることもある。今日は、教科書には載っていない「現場の感覚」を交えながら、この最重要パラメータについて深掘りしていこう。
—
shared_buffersの正体：データベースの「作業机」
`shared_buffers` は、PostgreSQLがテーブルやインデックスのデータをメモリ上にキャッシュしておくための領域だ。
例えるなら、「デスクの広さ」だと思ってほしい。
仕事をする際、デスクが広ければ資料をたくさん広げておけるよね？ 必要なデータがデスク（メモリ）にあれば、わざわざ遠い本棚（ディスク）まで取りに行く必要がない。これがヒットすれば、クエリは爆速になる。
逆に、デスクが狭すぎるとどうなるか。必要なデータを出すたびに本棚まで往復する羽目になる。これがディスクI/Oのボトルネックだ。
—
現場での「黄金比」は存在するのか？
ネットを探せば「メモリの25%」なんて数字がよく出てくる。確かにこれは一つの目安にはなるけれど、鵜呑みにするのは危険だ。
OSのキャッシュを忘れるな
PostgreSQLは、実はOSのキャッシュ（カーネルのページキャッシュ）にも大きく依存している。PostgreSQLがメモリを抱え込みすぎると、OS側でキャッシュする余裕がなくなって、結果的にトータルパフォーマンスが落ちることもあるんだ。
- 小〜中規模（メモリ数GB〜16GB程度）： 25%くらいから始めてみるのが安全。
- 大規模（メモリ64GB以上）： 25%にこだわらず、もっと積んでいい。ただし、メモリを食わせすぎるとOSがスワップアウトし始めるので、サーバー全体の負荷状況を見ながら調整が必要だよ。
—
チューニング前の「現状確認」がすべて
闇雲に数値をいじるのは、目隠しでドライブするのと同じ。まずは今のキャッシュ効率を見てみよう。`pg_stat_statements` を入れているなら、以下のクエリでヒット率を確認してほしい。
SELECT
sum(heap_blks_read) as disk_read,
sum(heap_blks_hit) as cache_hit,
(sum(heap_blks_hit) – sum(heap_blks_read)) / sum(heap_blks_hit + heap_blks_read) as hit_ratio
FROM pg_statio_user_tables;
もし `hit_ratio` が99%を超えているなら、今の `shared_buffers` は十分優秀だ。逆にここが低いなら、増やす余地がある。
—
設定変更のポイントと注意点
設定を変えるときは、`postgresql.conf` をいじることになる。
postgresql.conf
shared_buffers = 4GB # サーバーメモリが16GBの場合の例
ここで一つ、僕から重要なアドバイス。
「一度に大きく変更しすぎないこと」。
特に本番環境でいきなり数値を跳ね上げると、PostgreSQLの起動時に共有メモリの確保で失敗したり、予期せぬカーネルパラメータ（`shmmax` など）の制限に引っかかることがある。変更したら、必ず再起動後のログでエラーが出ていないか確認する癖をつけておこう。
—
結論：チューニングは「測定」に始まり「測定」に終わる
最後にこれだけは伝えておきたい。`shared_buffers` を増やせばすべての問題が解決するわけじゃない。
- インデックスが適切か？
- クエリの書き方は最適か？
- VACUUMはちゃんと走っているか？
これらが整って初めて、`shared_buffers` という「高性能なデスク」が活きてくるんだ。まずは現状のヒット率を計測して、そこから少しずつ調整していく。地味だけど、この積み重ねが、結局一番の近道だよ。
もし設定を変えてみて「あ、レスポンスが明らかに軽くなったな」という瞬間があれば、それが君の勝ちだ。応援してるよ。また何かあればいつでも聞いてくれ。
コメント