その「コミット待ち」、実はチューニングできるんです：PostgreSQLの `commit_delay` を使いこなす
エンジニアの皆さん、お疲れ様です。
PostgreSQLを運用していると、必ず一度はぶち当たる壁がありますよね。「高負荷時、書き込み処理がボトルネックになって頭打ちになる」という現象です。インデックスを削ったり、クエリを最適化したりしても限界がある……そんな時、データベースの「心臓部」であるWAL（Write Ahead Log）の書き込み戦略を見直すのが、プロのエンジニアの腕の見せ所です。
今日は、そんな時にそっと手を差し伸べてくれる隠し味、`commit_delay` についてお話しします。
そもそも、なぜコミットは「重い」のか？
PostgreSQLがトランザクションをコミットする際、データはまずWALというログファイルに書き込まれます。ここで重要なのが、「物理ディスクへのフラッシュ（fsync）」です。
ACID特性を保証するため、PostgreSQLは「ディスクに書き込みが終わるまで、ユーザーに『完了しました』とは言わない」という厳格なルールを守っています。しかし、この「ディスク待ち」が頻発すると、CPUはヒマなのにディスクI/Oのレイテンシで処理が詰まる……いわゆる「IO Wait地獄」に陥ります。
そこで登場するのが `commit_delay`
`commit_delay` は、一言で言うと「コミットのタイミングをわざと少しだけ遅らせて、仲間を待つ」という設定です。
「え、遅くするの？」と思いましたか？ そうなんです。でも、これには明確な理由があります。複数のトランザクションが同時進行している時、バラバラにディスクへ書き込みに行くよりも、少しだけ待って「まとめて（グループコミット）」書き込んだ方が、I/Oのオーバーヘッドが劇的に減るからです。
仕組みをイメージしてみよう
イメージとしては、バスの運行に近いかもしれません。
- デフォルト： 乗客が1人来るたびに出発する（効率が悪い）
- commit_delayあり： 「あと10マイクロ秒待てば次の客が来るかも」と待機し、数人をまとめて運ぶ（効率がいい）
実践：どう設定すればいいのか？
設定は `postgresql.conf` で行います。
デフォルトは 0 (マイクロ秒)
1000〜5000 くらいから試すのが定石です
commit_delay = 1000
ここで大切な注意点が2つあります。
1. `commit_siblings` とセットで考える：
`commit_delay` だけ設定しても実は意味がありません。`commit_siblings` という設定も必要です。これは「他に少なくともこれだけ並行トランザクションが走っていたら、待機するよ」という条件です。
commit_delay = 1000 # 1ms待機
commit_siblings = 5 # 5つ以上のトランザクションがアクティブなら待機を開始
2. 「銀の弾丸」ではない：
この設定が輝くのは、「多数の小さなトランザクションが頻繁に発生している」環境です。バッチ処理のように数秒かかる巨大なトランザクションには効果がないどころか、無駄な待機時間が増えるだけです。
現場でのチューニング戦略
僕が現場でこれを調整する時は、こんなステップを踏みます。
1. 現状分析： `pg_stat_activity` や `iostat` を見て、I/O待ちがボトルネックか確認する。
2. ベースライン計測： ベンチマークツール（`pgbench` など）で、現在のTPS（1秒あたりのトランザクション数）を測る。
3. 段階的な投入： いきなり大きな値は入れない。`100`→`500`→`1000` と少しずつ上げ、TPSが向上するか、あるいはレイテンシが悪化しすぎないかを確認する。
もし設定して逆に遅くなったなら、それは環境に合っていない証拠。潔く `0` に戻しましょう。データベースのチューニングは「引き算」も大事なんです。
最後に：エンジニアとしての心得
`commit_delay` は、PostgreSQLの奥底にある挙動を制御する、少しマニアックなパラメータです。設定一つで劇的にスループットが改善することもありますが、逆にシステム全体に妙な「溜まり」を作ってしまうリスクもあります。
だからこそ、本番環境でいきなり変えるのではなく、必ずステージング環境で負荷テストを行ってください。「なぜその値にしたのか」を論理的に説明できる準備をしてから投入する。それが、僕らプロのエンジニアの流儀です。
皆さんのシステムが、今日も軽快に動くことを願っています。それでは！
コメント