やあ。また会ったね。今日はPostgreSQLの「心臓部」の話をしようか。
DBのチューニングをしていると、必ず行き着くのが「書き込み性能」のボトルネックだよね。特にトランザクション量が多いシステムで、なぜログの書き出しがこれほど重要なのか、その裏側にあるWAL（Write Ahead Logging）バッファとwal_writerの挙動について、少し深掘りしてみよう。
マニュアルを読めば書いてあることだけじゃなく、「現場でどう動いているか」という視点で話すから、ぜひコーヒーでも片手に読んでみてくれ。
—
WALバッファは「一時的な待合室」
まず基本から。PostgreSQLはデータの整合性を守るために、データページをいきなりディスクに書き換えることはしない。まずは変更内容を「WAL」というログに書き出し、それを永続化してから、ゆっくりとメモリ上のデータページを更新する（これをWALプロトコルと言うんだ）。
この時、WALデータが一時的に溜まる場所がWALバッファ（共有メモリ）だ。
- 役割: プロセスがコミットを要求した際、まずはこのバッファにログを書き込む。
- ポイント: ここが溢れると、書き込みプロセスはフラッシュが終わるまで待たされることになる。だから、ここがボトルネックになると一気にパフォーマンスが落ちるんだ。`wal_buffers`の設定値は、高負荷な環境なら標準の16MBから増やしてやるのが定石だね。
wal_writer：縁の下の力持ち
さて、バッファに溜まったデータは、いつディスクに書き込まれるのか？ ここで登場するのがwal_writerプロセスだ。
こいつはバックグラウンドで絶えず動いていて、一定の間隔（`wal_writer_delay`）でWALバッファの中身をディスクにフラッシュしてくれる。いわば「定期便」みたいなものだ。
しかし、ここで面白いジレンマがある。
1. wal_writerにお任せすると…: 負荷は低い。でも、障害が起きた時に数ミリ秒〜数十ミリ秒分のデータがロストする可能性がある。
2. その都度フラッシュすると…: 整合性は完璧だけど、ディスクI/Oが激しくなってシステム全体が重くなる。
このトレードオフを制御するのが、我々エンジニアの腕の見せ所というわけだ。
同期コミット（synchronous_commit）の使い分け
現場で一番悩むのがここだろう。`synchronous_commit`をどう設定するか。
- `on`（デフォルト）: 「ディスクに書き込むまでクライアントにOKを返さない」。堅牢だけど、ネットワークやストレージが遅いと、コミットのたびにレイテンシが発生する。
- `off`: 「メモリに乗った時点でOKを返す」。爆速だけど、OSのクラッシュでデータが飛ぶリスクがある。
先輩からのアドバイス:
「性能が出ないからといって、安易に`off`にしてはいけない」。
もし、どうしても性能を稼ぎたいなら、まずは`fsync`の方式を見直すか、ストレージのI/O性能を上げるのが先だ。どうしても許容できるなら、ログを失っても再生成可能な「非クリティカルなキャッシュテーブル」の更新だけに限定して`off`にする、といった運用上の工夫が必要だよ。
現場でチェックすべきメトリクス
実務で「あれ、なんか遅いな？」と思ったら、まずはこのあたりを見てほしい。
— WALの書き込み待機が発生しているかを確認するクエリ
SELECT
wait_event_type,
wait_event,
count()
FROM pg_stat_activity
WHERE wait_event_type = ‘WALWrite’
GROUP BY 1, 2;
もし`WALWrite`というイベントがたくさん見えたら、ディスクへの書き込みが追いついていない証拠だ。ストレージのIOPSが限界なのか、あるいは`checkpoint_completion_target`の設定が甘くて、チェックポイント時にI/Oがスパイクしている可能性がある。
最後に：完璧な設定なんてない
PostgreSQLのアーキテクチャの面白いところは、「すべてを解決する魔法の設定値」が存在しないことだ。
- トランザクションが短いなら`wal_writer_delay`を短くしてこまめにフラッシュする。
- 書き込みが超大量なら、`max_wal_size`を広げてチェックポイントの頻度を下げ、ディスクの負担を減らす。
君が担当しているシステムの「データの重要度」と「許容できるレイテンシ」のバランスを、このWALの仕組みを理解した上で設計してみてほしい。
もし迷ったら、いつでも聞いてくれ。アーキテクチャを理解していれば、DBは決して君を裏切らないから。
それじゃ、また現場で会おう。
コメント