【テクニカル・上級編】 CLOG (Commit Log) – PostgreSQL

PostgreSQLの心臓部を覗く：CLOGが語るトランザクションの「真実」

PostgreSQLのアーキテクチャを語る上で、避けて通れないコンポーネントがいくつかあります。MVCCを実現するための`tuple header`の情報や、WALの物理的な書き込み順序……どれも重要ですが、今回スポットを当てたいのは、トランザクションの「生死」を司るCLOG (Commit Log) です。

「`pg_xact`（旧称 `pg_clog`）なんて、単なる状態管理ビットマップでしょ？」と思っているなら、少し立ち止まって考えてみてください。この小さなファイル群が、PostgreSQLの並行制御の根幹をどう支えているのか。そして、高負荷なシステムでなぜこれがボトルネックになり得るのか。

今日は、そんな深淵に少しだけ足を踏み入れてみましょう。

—

CLOGの正体：わずか2ビットの重み

CLOGは、各トランザクションID (XID) に対して、以下の4つのステータスのいずれかを記録するビットマップです。

IN_PROGRESS: 進行中
COMMITTED: コミット済み
ABORTED: アボート済み
SUB_COMMITTED: サブトランザクション用

ご存知の通り、PostgreSQLはXIDの再利用（Wraparound）を避けるために、非常に緻密なID管理を行っています。そして、ある行（Tuple）が「今、自分から見えるか？」を判断する際、エンジンは`xmin`と`xmax`を確認し、そのXIDの状態をCLOGに問い合わせます。

ここで重要なのは、「CLOGへのアクセスは頻繁であると同時に、極めて局所的である」という点です。

なぜCLOGがボトルネックになるのか

パフォーマンスチューニングの現場で、ときどき遭遇するのが「CLOGのロック競合」です。

CLOGは、共有メモリ上にキャッシュ（`CLOG Buffers`）され、ディスク上の `pg_xact` ディレクトリに書き出されます。通常、CLOGは非常にコンパクトなので、メモリ内に収まり、読み取りは高速です。しかし、高並行な環境では問題が浮き彫りになります。

LWLockの競合: 複数のバックエンドが同時にCLOGの状態を更新・参照しようとする際、`CLogControlLock` が激しく競合します。特に、大量の短いトランザクションを秒間数万回捌くようなOLTPワークロードでは、CPUのクロック数よりも、この「ロック待ち」がスループットの天井になることがよくあります。
I/Oの局所的負荷: 巨大なトランザクションがアボートした際や、大量のコミットが発生したとき、チェックポイントのタイミングで `pg_xact` がフラッシュされます。この際、ファイルシステムレベルでの書き込みレイテンシが、トランザクションのコミット遅延として跳ね返ってきます。

プロフェッショナルが注目すべき「兆候」

皆さんが運用するデータベースで、もし「特定の時間帯にCPU使用率がサチるのに、クエリの実行計画には問題がない」という状況に陥ったら、`pg_stat_activity` を眺めるだけでなく、ぜひ `pg_stat_lwlock`（拡張機能を入れているなら）や、`perf` を使ったシステムコール解析を試してみてください。

特に、`CLogControlLock` が上位に顔を出しているなら、それはCLOGが悲鳴を上げているサインです。

対策のヒント:
1. トランザクションを短く保つ: 基本中の基本ですが、やはりこれが最強です。
2. バッファの最適化: `shared_buffers` のサイズはもちろんですが、CLOGそのもののバッファは自動調整されるとはいえ、OS側のディスクI/Oスケジューラやファイルシステムのレイテンシが足を引っ張っていないか確認してください。NVMe SSDなどへの移行は、CLOGの書き込み待ちを劇的に改善します。
3. アーキテクチャの見直し: あまりにCLOG競合が激しい場合、それはPostgreSQLの設計限界ではなく、データモデリングやアプリケーション側の並行制御設計を見直すべきサインかもしれません。

最後に：データベースは「ログ」でできている

CLOGを見ていると、PostgreSQLというシステムが、いかにして「楽観的」かつ「堅牢」にデータを管理しているかを実感します。たった2ビットの情報に、トランザクションの全責任を負わせる。このシンプルさこそが、PostgreSQLが四半世紀にわたって信頼され続けている理由ではないでしょうか。

もし皆さんの現場で、この静かな功労者であるCLOGがトラブルの種になっているとしたら、それは皆さんのシステムが、PostgreSQLの限界に挑むほど成長した証なのかもしれません。

次はどのコンポーネントを覗きましょうか。`MultiXact`あたりも、なかなか奥が深くて面白いですよ。

それでは、また次回の深掘りでお会いしましょう。