グループコミットとfsyncバッチングの内部

コミットのレイテンシは fsync が決める

WAL（先行書き込みログ）を使う DBMS では、トランザクションのコミットを確定させる最後の一歩は「コミットログレコードまでを永続ストレージへ確実に書く」ことです。これは OS のページキャッシュを実デバイスまで届ける fsync（または fdatasync）の呼び出しで実現します。

問題は fsync の物理的なコストです。回転ディスクなら 1 回数ミリ秒、SSD でも数十〜数百マイクロ秒、停電保護付き書き込みキャッシュ（バッテリバックアップ）が無ければさらに遅くなります。ここで素朴に「コミットのたびに 1 回 fsync」を守ると、1 つのコミットが終わるまで次の fsync を開始できない直列実行になり、スループットの上限はおおむね次式に張り付きます。

最大コミット率 ≒ 1 / (fsync 1 回のレイテンシ)
例: fsync = 5 ms なら 最大 200 コミット/秒（並行数をいくら上げても）

並行トランザクションを 1000 本走らせても、fsync が直列なら全員がこの細い口を通ることになります。これがコミットのボトルネックの正体です。

グループコミットの基本原理

fsync は「呼んだ時点までにバッファへ書かれた全データ」をまとめて永続化します。つまり 1 回の fsync の中に、複数トランザクションのコミットログを同時に含められます。ここがグループコミット（group commit）の出発点です。

短い時間窓の間に到着したコミットのログをログバッファ上で連結し、まとめて 1 回の fsync で永続化します。N 件束ねれば fsync 回数は 1/N になり、同じハードウェアでもコミット率が N 倍近くまで伸びます。

個別コミット:    T1→fsync  T2→fsync  T3→fsync     （fsync 3 回・直列）
グループコミット: [T1,T2,T3 のコミットログを連結] → fsync 1 回で全員確定

重要なのは、束ねても永続性が一切緩まない点です。各トランザクションは「自分のコミット LSN まで flushedLSN（永続化済みログの末尾）が進んだ」ことを確認してからクライアントへ完了応答します。1 回の fsync が複数のコミット LSN をまとめて追い越すので、全員が安全に確定します。

リーダー・フォロワー方式の実装

実装の中核は「誰が fsync を呼ぶか」の調停です。代表的なのがリーダー・フォロワー方式（leader/follower、または slot 方式）です。

擬似コードで書くとこうなります。地の文の波括弧を避けるため、ブロックはコードとして示します。

commit(txn):
  enqueue(txn)                      # コミット待ち行列に登録
  if first_in_queue(txn):           # 自分がリーダー
    wait_briefly()                  # 後続が溜まる窓を開ける（任意）
    batch = drain_queue()           # 今いる全員を取り込む
    write_log(batch)                # コミットログをバッファへ連結
    fsync()                         # 1 回の物理同期
    publish flushedLSN = max_lsn(batch)
    wake_followers(batch)
  else:                             # 自分はフォロワー
    wait_until(flushedLSN >= txn.commit_lsn)
  return committed

この方式の利点は、fsync が走っている間に到着したコミットが自然に次のバッチへ吸い込まれることです。fsync のレイテンシそのものが「束ねる窓」として機能するため、明示的な待機をゼロにしても、負荷が高いほど勝手にバッチが大きくなる自己調整が効きます。これをパイプライン化したのが MySQL の binary log group commit で、flush・sync・commit の 3 ステージを別々のキューで回し、各ステージのリーダーが順送りに次のバッチを処理します。

レイテンシとスループットのトレードオフ

グループコミットの設計判断は、つまるところ「リーダーがどれだけ後続を待つか」に集約されます。待機窓を W、平均到着率を λ とすると、1 バッチに集まる件数はおおよそ λ × W です。

• 窓 W を大きくする → バッチが大きく fsync 回数が減りスループット↑。ただし各トランザクションは平均 W/2 程度の追加待ちを背負うのでコミットレイテンシ↑。
• 窓 W を小さく（あるいは 0）→ レイテンシは最小だが、低負荷ではほとんど束ねられず fsync を打ちまくることになりスループット↓。

ここに非自明な点があります。低負荷で固定の待機窓を入れるのは純粋な損です。後続が来ないのに W だけ待ち、結局 1 件で fsync するので、レイテンシだけ悪化して何も束ねられません。逆に高負荷では、暗黙的グループコミットだけで十分大きなバッチが形成され、明示的な待機はほぼ不要になります。だから実用実装は待機窓を負荷に応じて適応させます。

MySQL の binlog_group_commit_sync_delay / ..._sync_no_delay_count、PostgreSQL の commit_delay / commit_siblings は、まさにこの「窓をどれだけ開け、何件溜まったら待たずに飛ばすか」を露出したパラメータです。commit_siblings は「他にアクティブなトランザクションがこれ以上いるときだけ待つ」という条件で、低負荷での無駄待ちを避ける適応の一形態です。

永続性をどこまで譲るか

グループコミットは永続性を保ったままスループットを上げる手法ですが、隣には「永続性を一部諦めて速くする」設定があり、混同しがちなので切り分けます。

• グループコミット: 各コミットは必ず自分の fsync 完了を待つ。永続性は完全。束ねるだけ。
• 非同期コミット（asynchronous commit）: クライアントへの応答を fsync 完了より前に返す。クラッシュ時に直近の確定済みコミットが失われ得る（ただし WAL ルールにより DB の論理的整合性自体は壊れない）。

両者は直交します。同期コミットのままグループコミットで束ねるのが基本戦略で、レイテンシ要件がさらに厳しい一部処理だけ非同期コミットに落とす、という使い分けが現実的です。

まとめ

コミットの速さを最終的に縛るのは fsync の物理レイテンシであり、コミットごとに 1 回呼ぶ素朴な実装ではその逆数がスループット上限になります。グループコミットは複数トランザクションのコミットログを 1 回の fsync に束ねてこの上限を押し上げる手法で、永続性は一切緩めません。鍵はリーダー・フォロワーによる fsync の調停と、fsync 実行中に来たコミットを次バッチへ吸い込む暗黙のバッチ化です。残るのは待機窓のチューニング――束ねる量とレイテンシのトレードオフであり、負荷に応じて窓を適応させるのが定石です。レプリケーションの同期モード（同期・準同期・非同期レプリケーション）やコネクションプーリングと組み合わせて、初めてコミット経路全体のスループットが設計可能になります。