PostgreSQLの「LWLock」と仲良くなる：高負荷でも死なないシステムを作るために
やあ。最近、PostgreSQLのパフォーマンスチューニングにどっぷり浸かっているかい？
DBのログを見ていて「`LWLock`」という単語に遭遇して、ドキュメントを読み漁ったものの、「結局、スピンロックと何が違うの？」「なぜこれがボトルネックになるの？」と頭を抱えた経験はあるだろう。
今日は、そんなPostgreSQLの縁の下の力持ち、「LWLock（Lightweight Lock）」について、教科書的な説明はすっ飛ばして、現場のエンジニアが知っておくべき「勘所」を話していくよ。
—
1. LWLockは「渋滞の交通整理」係だ
PostgreSQLの共有メモリ（Shared Bufferなど）は、複数のバックエンドプロセスから同時にアクセスされる戦場だ。もし、誰かがデータを書き込んでいる最中に別の誰かが読み書きしたら、メモリは一瞬で破壊される。
そこで登場するのがロック機構だけど、PostgreSQLには大きく分けて2種類ある。
- スピンロック (Spinlock): とにかく「今すぐロック取る！無理ならループして再試行！」という力技。非常に高速だけど、CPUを空回り（ビジーウェイト）させるから、長時間占有するのには向かない。
- LWLock (Lightweight Lock): ここが今回の主役。ロックが取れなかった場合、「待機キュー」に入って、OSのスケジューリングに身を委ねる。
つまり、LWLockは「短時間〜中時間のアクセス保護」担当で、CPUを無駄遣いせずに他のプロセスに順番を譲るという、非常に賢い仕組みなんだ。
—
2. 実務でよく見る「LWLock」の正体
現場でよく見かけるのは、`LWLock`の待ち時間が増加しているケースだ。特に「Buffer Content」や「WAL Write」といったキーワードが目に付くはず。
なぜ詰まるのか？
LWLockは「共有データ構造」を守るための門番だ。例えば、こんな場所で使われている。
- Buffer Content Lock: 共有バッファのページを読み書きするとき。ここが激しく競合するのは、特定のテーブルにアクセスが集中している証拠だ。
- WAL Write Lock: WAL（Write Ahead Log）を書き出すとき。トランザクションが多すぎて、ディスクへの書き込みが追いついていないとここが詰まる。
—
3. コードレベルで見る「ロックの作法」
PostgreSQLのソースコード（C言語）を覗くと、LWLockの使い方は意外とシンプルだ。基本的には「`LWLockAcquire`」で取って、「`LWLockRelease`」で解放する。
/ 例：共有メモリ上の何かを保護する擬似コード /
LWLockAcquire(MyCustomLock, LW_EXCLUSIVE); // 排他ロックを取得
/ — ここで共有メモリ上のデータにアクセス — /
shared_data->counter++;
LWLockRelease(MyCustomLock); // 解放
もし、読み込みしかしないなら「`LW_SHARED`」を使う。これで「書き込み待ち」と「読み込み待ち」をうまく分離できる。ここを間違えて常に`LW_EXCLUSIVE`（排他）を貼っているコードを書くと、即座にパフォーマンス劣化の戦犯になるから注意してくれよな。
—
4. 現場の先輩からのアドバイス：どう対処するか？
もし、監視ツールで「LWLockの待ち時間が異常に長い！」と警告が出たら、以下の手順で原因を切り分けよう。
1. pg_stat_activityを確認する: どのプロセスが今何を待っているのか？ `wait_event_type` が `LWLock` になっているプロセスを探せ。
2. アクセスの偏りがないか？: 特定のテーブルへの頻繁な `UPDATE` や `INSERT` はないか？ `pg_stat_user_tables` で `n_tup_upd` などを確認して、ホットスポットを見つけるんだ。
3. IOを確認する: WAL周りのロックなら、ディスクI/Oがボトルネックだ。`checkpoint_completion_target` の調整や、WALログを置いているディスクの高速化を検討するフェーズだね。
—
最後に
LWLockは、PostgreSQLがマルチコア・マルチプロセス環境で整合性を保つための「大動脈」だ。ここが詰まるということは、システム全体が悲鳴を上げているということでもある。
「なぜロックが必要なのか？」「どうすれば競合を減らせるか？」を意識してクエリやインデックスを設計できるようになると、君のエンジニアとしてのレベルは一段階上がるはずだ。
次は、実際に `pg_stat_lwlock` を眺めながら、自分の環境でどのロックが一番働いているか調べてみるといい。案外、面白い発見があるはずだよ。
それじゃ、また現場で会おう。健闘を祈る！
コメント