【実務・中級編】共有バッファ – PostgreSQL

PostgreSQLの心臓部、「共有バッファ」を理解してパフォーマンスの闇を突き抜ける

やあ。データベースのパフォーマンスチューニングに足を踏み入れたんだね。いい選択だよ。

PostgreSQLを触っていると、必ずぶつかる壁がある。「なぜかクエリが遅い」「ディスクI/Oがボトルネックになっている」というやつだ。そのとき、多くのエンジニアはとりあえずインデックスを貼ってみたり、クエリを書き直したりする。それは正しいんだけど、もう少し深い場所――そう、PostgreSQLの共有バッファ（Shared Buffers）を知っているだけで、打てる手の解像度が劇的に変わるんだ。

今日は、この「メモリの要塞」について、教科書には載っていないような現場の感覚を交えて話そうと思う。

—

共有バッファって、結局なんなのか？

一言で言えば、「ディスク上のデータページをメモリ上に展開して、高速にアクセスするためのキャッシュ」だ。

データベースにおいて、ディスクへのアクセスは「絶望的に遅い」。メモリへのアクセスがナノ秒単位なら、ディスクはミリ秒単位。数万倍の差がある。だから、PostgreSQLは賢いんだ。一度読み込んだデータは、ディスクに戻さず、この「共有バッファ」という領域に置いておく。次に同じデータが必要になったら、ディスクを見に行かずにメモリから直接返す。

これがキャッシュヒットだ。これができている限り、DBは爆速で動く。

なぜ「共有バッファ」の設定が重要なのか

多くのエンジニアが陥る罠が「とりあえずデフォルト値のまま放置する」ことだ。PostgreSQLのデフォルト値は、かなり控えめに設定されていることが多い。なぜかって？どんな環境でも最低限動くようにするためだ。

でも、本番環境でこれをやると、OSのキャッシュ（カーネルページキャッシュ）に頼りすぎることになる。

共有バッファ（DB側）: データの構造（行レベル）を理解している。
OSキャッシュ: 単なるブロックの集まりとしてしか理解していない。

DBの内部構造を理解している共有バッファの方が、圧倒的に効率が良いんだ。だから、メモリに余裕があるサーバーなら、このバッファを適切に大きく確保してやる必要がある。

実践的なチューニングの勘所

現場での経験則を一つ教えるよ。`shared_buffers` の設定だ。

よく「メモリの25%に設定せよ」なんて言われるけれど、あれはあくまで目安。大規模なDBなら、25%どころかもっと積んでもいい場合がある。逆に、小さすぎる環境で欲張りすぎると、今度はOS側がメモリ不足でスワップアウトを起こして地獄を見る。

— 現在のバッファサイズを確認
SHOW shared_buffers;

— 実際にどれくらいキャッシュされているか調べる (pg_buffercache拡張が便利)
CREATE EXTENSION pg_buffercache;

SELECT count() AS buffers,
c.relname,
pg_size_pretty(count() 8192) AS size
FROM pg_buffercache b
JOIN pg_class c ON b.relfilenode = pg_relation_filenode(c.oid)
GROUP BY c.relname
ORDER BY buffers DESC
LIMIT 10;

このクエリを叩いてみてほしい。「今、どのテーブルがメモリを占拠しているか」が丸見えになる。これを見て、「ああ、この巨大なテーブルがメモリを食いつぶしているから、他の小さなテーブルのアクセスが遅くなっているんだな」と推測する。これがチューニングの第一歩だ。

「クロック・スイープ法」という面白い仕組み

共有バッファが満杯になったらどうなるか？新しいページを読み込むために、古いページを追い出さなきゃいけないよね。このアルゴリズムが「クロック・スイープ（Clock Sweep）」だ。

簡単に言うと、バッファリングされているデータに対して「最近使った？」というフラグを立てておいて、一周回ってくる間に使われていなかったら容赦なく捨てるという仕組みだ。

ここで大事なのが、「キャッシュの汚染（Cache Pollution）」を避けること。例えば、巨大なテーブルをフルスキャンするようなバッチ処理を走らせると、共有バッファの中身がそのデータで塗り替えられてしまう。結果として、本来メモリ上にあったはずの重要なインデックスまで追い出されて、システム全体が急激に重くなることがある。

現場では、こういうバッチ処理を時間帯で分けるか、あるいは `pg_prewarm` なんかを使って、必要なデータをあらかじめメモリにロードしておくような工夫が必要になることもあるね。

先輩からのアドバイス

「共有バッファを増やせばすべて解決する」なんて魔法はない。DBのパフォーマンスは、クエリの質、インデックスの設計、そしてメモリ管理のバランスの上に成り立っている。

でも、共有バッファの仕組みを理解しているエンジニアは、「なぜここでディスクI/Oが発生しているのか？」を自分の頭でシミュレーションできる。これは、トラブルシューティングのときに最強の武器になるよ。

まずは `pg_buffercache` を入れて、自分のDBの「今」を覗いてみてごらん。きっと、今まで見えなかった新しい景色が見えるはずさ。

何か困ったことがあったら、またいつでも聞いてくれ。応援しているよ。