【テクニカル・上級編】ラッチ (Latch) – PostgreSQL

PostgreSQLの「静かなる守護者」：ラッチ（Latch）の深淵を覗く

PostgreSQLのアーキテクチャを語る上で、ロック（Lock）やLWLocks（Lightweight Locks）に注目するエンジニアは多い。しかし、それらの裏側で、プロセスを適切に眠らせ、そして絶妙なタイミングで起こすという「指揮者のような役割」を果たしているのが「ラッチ（Latch）」だ。

今回は、このラッチがPostgreSQLのプロセス間通信（IPC）の心臓部でどう機能しているのか、その深淵を少し掘り下げてみたいと思う。

—

なぜ、単なるSleepではダメなのか

PostgreSQLはプロセスベースのアーキテクチャだ。高負荷な環境では、何百ものバックエンドプロセスが同時に走り、共有メモリ上の資源を奪い合う。ここで重要なのが「待ち」の効率性だ。

もしプロセスが共有資源を待つ際に、ただのループでフラグを確認する「スピンロック」を使い続けたらどうなるか。CPUは100%に張り付き、電力とクロックサイクルを浪費する。逆に、単純な `sleep()` を呼び出せば、資源が解放された瞬間に反応できず、レイテンシが跳ね上がる。

ここで登場するのが、PostgreSQLのラッチだ。これは単なる待機フラグではない。カーネルレベルの同期プリミティブ（Linuxなら `epoll` や `signalfd` など）と密接に連携し、プロセスを「休止状態」に追い込みつつ、通知が来れば即座に叩き起こすための、極めて洗練されたOSインターフェースのラッパーなのだ。

ラッチの正体：シグナルとパイプの狭間で

PostgreSQLにおけるラッチは、`WaitEventSet` という抽象化レイヤーを通じて管理されている。かつてのPostgreSQLは、プロセスごとに専用のパイプを一つ持ち、そこに書き込むことでシグナルを伝えていたが、これはファイルディスクリプタを大量消費するという弱点があった。

現在のラッチ構造が優れているのは、「OSのウェイトイベント機構を最大限活用している点」だ。

`Latch` 構造体: プロセス固有のメモリ領域に存在し、`is_set` というアトミックなフラグを持つ。
通知の仕組み: あるプロセスが別のプロセスを起こしたいとき、対象プロセスのラッチにフラグを立て、OSに対して「このプロセスを起こせ」というシグナル（`SIGUSR1`など）を送る。
効率的な待機: 待機側は `WaitLatch()` を呼び出すことで、OSのイベントループに自身を登録し、カーネルに「何かが起こるまでCPUを明け渡す」ことを伝える。

この仕組みのおかげで、PostgreSQLのバックエンドは、何もすることがない時には驚くほど静か（アイドル状態）でいられるし、トランザクションのコミットやWALの書き込み完了といったイベントに対しては、ミリ秒以下のラグで反応できるのだ。

パフォーマンストラブルシューティング：どこを見るべきか

「ラッチの待ち時間が長い」という事象に直面したとき、それは往々にして「ラッチそのものの問題」ではなく、「ラッチを待たせているリソースの競合」を示唆している。

1. `pg_stat_activity` と `wait_event_type`

まず確認すべきは `pg_stat_activity` だ。`wait_event_type` が `Latch` になっているプロセスが大量にいる場合、それは「何かを待っている状態」に過ぎない。重要なのは、そのプロセスが「何のために」待っているかだ。

WALWriteLatch: WALの書き込み待ち。ディスクI/Oのボトルネックか、`fsync`の遅延が疑われる。
ProcSignalLatch: プロセス間シグナル。クエリのキャンセルや、バックエンド同士の協調動作で発生する。

2. ストールとコンテキストスイッチの罠

もしシステム全体のパフォーマンスが低下し、`Latch` 待ちが多発している場合、OS側のカーネル統計も併せて見る必要がある。過剰なコンテキストスイッチが発生していないだろうか？

あまりに頻繁なラッチのセット・リセットが繰り返されると、カーネルのシグナル処理コストが無視できない重荷になる。これは、特定のロック（Heavyweight Lock）の競合が激しすぎて、プロセスが頻繁にスリープとウェイクアップを繰り返す「スレッシング（Thrashing）」に近い現象を引き起こしていることが多い。

最後に：ラッチは「呼吸」である

私にとって、ラッチはPostgreSQLという巨大な生命体の「呼吸」のようなものだ。吸って、止めて、吐き出す。このリズムが乱れると、データベースは途端に息苦しくなり、レスポンスを悪化させる。

チューニングの際、パラメータをいじって「何となく速くなった」で終わらせるのではなく、OSのイベントループとプロセスがどう対話しているのかを想像してみてほしい。そうすれば、`wait_event` の向こう側に、PostgreSQLが必死に調和を保とうとしている姿が見えてくるはずだ。

データベースエンジニアとしての醍醐味は、こうした「見えない同期」を最適化し、システムの鼓動を整えることにこそあるのだから。