「PostgreSQLの共有メモリって、結局何のためにあるの？」
新人エンジニアからこう聞かれたら、僕はいつもこう答えるんだ。「あれは、PostgreSQLという巨大なオーケストラが、全員で楽譜を共有するための『ステージの真ん中に置かれた巨大な譜面台』なんだよ」って。
今日は、PostgreSQLの心臓部、共有メモリ（Shared Memory）について、現場の視点から少し深掘りしてみようか。教科書に書いてあるような「プロセス間通信の効率化」なんて言葉だけじゃ、システムチューニングの勘所は掴めないからね。
—
なぜ「共有」メモリが必要なのか？
PostgreSQLは、接続されるたびに新しいプロセス（Postgresプロセス）をフォークするアーキテクチャだよね。もし、各プロセスが自分のメモリ空間だけで完結していたらどうなると思う？
- 「今、どのテーブルにロックがかかっているか」が誰にもわからない。
- 「メモリ上のキャッシュ（バッファ）にデータがあるか」を毎回ディスクに見に行かなきゃいけない。
- データの整合性を保つための「WAL（Write Ahead Log）の状態」を全プロセスが一致させられない。
つまり、共有メモリがないとPostgreSQLは単なる「独立した単体プログラムの集まり」になってしまうんだ。だからこそ、全プロセスが同じデータを見られる「共有の作業台」が不可欠なわけ。
共有メモリの「中身」を覗いてみよう
共有メモリの中には、いくつかの重要なエリアがある。特に意識してほしいのはこの3つだ。
1. Shared Buffer Cache（バッファプール）
- 言わずと知れた、ディスクI/Oを減らすための最重要エリア。データページがここに載っているかどうかで、クエリの速度が段違いに変わる。
2. Lock Table
- 今、誰がどの行をロックしているか。これがないと同時実行制御（MVCC）なんて夢のまた夢だ。
3. WAL Buffer
- 変更履歴をディスクに書き出す前の一時置き場。ここが溢れると、書き込み性能がガタッと落ちる。
チューニングの現場から：shared_buffersの罠
よく「`shared_buffers`はメモリの25%に設定せよ」なんてネット記事を見るよね。確かに目安としては正解なんだけど、現場で一番怖いのは「物理メモリの限界に触れること」なんだ。
共有メモリを大きくしすぎると、OS側でメモリ不足（OOM Killer）が起きてPostgresプロセスが強制終了されるリスクがある。特に、PostgreSQLの共有メモリは「一度確保したら基本的には解放されない（固定される）」という性質があるから、欲張りすぎには注意が必要だ。
実践的な確認方法
今、自分の環境で共有メモリがどうなっているか確認するなら、`pg_stat_activity`だけでなく、バックエンドから直接OSの情報を覗いてみるのもいい。
— 共有バッファの使用状況を簡易的に確認する（pg_buffercache拡張が必要）
SELECT count() AS buffers, usagecount
FROM pg_buffercache
GROUP BY usagecount
ORDER BY usagecount;
この`usagecount`が高いページが多いということは、頻繁にアクセスされる「熱いデータ」が共有メモリに定着している証拠だ。ここがうまく回っているなら、そのDBは健康そのものと言っていい。
最後に：エンジニアへのアドバイス
共有メモリは、いわば「PostgreSQLの脳内キャッシュ」だ。ここをいじるということは、脳の神経伝達速度をいじるようなもの。
「とりあえず値を大きくすれば速くなる」なんて安易な考えは捨てよう。まずは `pg_stat_bgwriter` でチェックポイントの発生回数を見たり、`pg_stat_statements` でクエリの実行効率を疑ったりするのが先だ。
メモリの設計は、DB運用の中で最も「地味だけど、最も劇的に効く」部分だよ。もし君がパフォーマンスに悩んだら、まずはこの共有メモリという「ステージ」が、今のデータ量や負荷に対して適切なサイズになっているか、一度立ち止まって考えてみてほしい。
現場からは以上！……おっと、次のタスクが待ってるんだ。また共有メモリの話、深掘りしたくなったら聞きに来てよ。
コメント