HADR_GROUP_COMMIT Wait Type in SQL Server

HADR_GROUP_COMMIT is recorded when transaction commit processing on an Availability Group primary waits briefly so that multiple commit records can be packed into a single log block. Group commit is an optimisation: fewer, fuller log blocks mean fewer flushes, captures, and sends across the AG pipeline, which is a good trade on busy systems.

The waits are the deliberate micro-delays (default threshold around 10ms) that make the batching possible.

Is It a Problem?

By design, no; it is an expected condition that optimises log I/O and AG send efficiency, and moderate accumulation on a busy AG primary is the feature working. The edge case worth knowing: on some workloads, the batching delay itself can cap transaction throughput, visible as this wait becoming prevalent while commits-per-second plateaus below what the hardware should manage.

For that specific situation, Microsoft documents two levers: trace flag 9546 disables group commit entirely, and KB 4565944 describes setting your own maximum group-commit threshold. Both are measured, deliberate changes, not defaults to flip.

Common Causes

• Normal AG group-commit batching under commit-heavy workloads.
• Very high commit rates where the batching delay becomes the throughput ceiling.

What To Do

1. Baseline first: is transaction throughput actually suffering, or is the wait just present? Present-but-harmless is the common case.
2. If throughput is genuinely capped, test the documented threshold adjustment (KB 4565944) in a controlled environment before considering trace flag 9546.
3. Keep the rest of the commit path healthy (log latency, HADR_SYNC_COMMIT levels); group commit tuning cannot compensate for a slow pipeline.

How To See It

Rank it against everything else with Get-WaitStatistics, alongside commit throughput counters and the broader AG wait picture.

Part of the SQL Server Wait Types Library.
Related deep dive: HADR_SYNC_COMMIT Wait Type.