「PostgreSQLの共有メモリって、結局何が詰まっているの？」
運用中に`huge_pages`の設定でつまずいたり、`shared_buffers`のチューニングで悩んだりしたとき、こんな疑問を抱いたことはありませんか？
ドキュメントを読めば「全プロセスで共有する領域」なんて書いてありますが、現場でトラブルシュートしているときにそんな教科書的な説明は役に立ちませんよね。今日は、PostgreSQLの心臓部である「共有メモリ」について、一歩踏み込んだ話をしましょう。
—
なぜ共有メモリが必要なのか？
PostgreSQLはマルチプロセスモデルです。クライアントから接続があるたびに新しい「バックエンドプロセス」が立ち上がります。
もし、各プロセスがメモリを完全に独立して持っていたらどうなるか？
「あるプロセスが更新したデータ」を別のプロセスが知るために、いちいちディスクを介さなきゃいけなくなりますよね。そんなことをしていたら、パフォーマンスは地獄です。
そこで登場するのが共有メモリ（Shared Memory）です。全プロセスが「同じ机」を囲んで、そこにデータを置くことで、高速な情報共有を実現しているわけです。
—
共有メモリの「住人たち」
共有メモリを覗くと、主に以下の3つの重要メンバーが陣取っています。
1. Shared Buffers（共有バッファ）
- 一番の「大食い」です。ディスク上のデータページをメモリ上にキャッシュしておく場所。ここがいかに効率的に使われているかが、PostgreSQLのパフォーマンスを左右します。
2. Lock Table（ロックテーブル）
- 「誰がどの行をロックしているか」を管理する共有の帳簿。これがないと、トランザクションの整合性が保てません。
3. WAL Buffers（WALバッファ）
- トランザクションの変更ログ（WAL）をディスクに書き出す前に一時保管するバッファ。ここが溢れると書き込み待ちが発生して、急激にレスポンスが悪化します。
—
現場で役立つチューニングの勘所
よく「Shared Buffersはメモリの25%に設定しろ」なんて言われますが、あれはあくまで目安。本質的な考え方はこうです。
- OSのキャッシュとのバランス:
PostgreSQLが共有バッファに置かなかったデータも、実はOSが「ページキャッシュ」としてメモリに保持してくれます。だから、共有バッファを巨大にしすぎると、逆にOS側で使えるメモリが減ってしまい、相殺されてしまうこともあるんです。
- 検証のコツ:
`pg_buffercache` 拡張を使えば、今どのテーブルやインデックスが共有メモリを占有しているか可視化できます。
— 共有メモリを占有している上位5つのリレーションを特定するクエリ
SELECT
c.relname,
count() AS buffers
FROM pg_buffercache b
INNER JOIN pg_class c ON b.relfilenode = pg_relation_filenode(c.oid)
AND b.reldatabase IN (0, (SELECT oid FROM pg_database WHERE datname = current_database()))
GROUP BY c.relname
ORDER BY 2 DESC
LIMIT 5;
これを見て、「あれ、頻繁にアクセスしないはずの古いテーブルが共有メモリを食いつぶしているぞ？」なんて気づきが得られたら、それがチューニングの第一歩です。
—
「メモリ不足」のサインを見逃さないために
実務で一番怖いのは、共有メモリの設定ミスでPostgreSQLが起動しなくなる、あるいはシステム全体がOOM Killerに殺されること。
特に`huge_pages`を有効にする場合は注意が必要です。OS側で大きなページサイズのメモリを確保しておく必要があるので、設定値が物理メモリを超えると、PostgreSQLは起動すらしてくれません。
先輩からのアドバイス：
まずは、設定変更を本番に反映する前に、以下のコマンドで現在の共有メモリの消費状況をざっくり把握する癖をつけましょう。
共有メモリセグメントの状態を確認
ipcs -m
これで、PostgreSQLが確保している「セグメント」が確認できます。もしここが想定外のサイズになっていたら、設定ファイル（`postgresql.conf`）を見直すサインです。
—
まとめ：メモリは「戦略」
共有メモリを単なる「設定値の集まり」と思わず、「どのデータを優先的にメモリに残し、どの処理を高速化させたいか」というデータベースの戦略そのものだと思ってください。
まずは現在の環境で、`pg_buffercache`を叩いて、自分のDBが今何を一番大事にしているのかを覗いてみてください。それができれば、あなたも立派なPostgreSQLエンジニアの仲間入りです。
また何か、具体的なトラブルや設定で迷ったら相談してくださいね。現場からは以上です！
コメント