CHECKPOINT_QUEUE is recorded by the background checkpoint process while it sits idle, waiting for the next checkpoint request to be placed on its queue. Between checkpoints there is nothing for it to do, so the wait accumulates continuously through the instance’s life.
Manual CHECKPOINT commands bypass this queue entirely, so they never touch this wait.
Is It a Problem?
No. It is a textbook benign wait: an always-on background thread measuring its own idle time. Its totals scale with uptime and how infrequently automatic checkpoints fire, and neither of those is a performance signal. It belongs on the filter list with LAZYWRITER_SLEEP and friends, and our Get-WaitStatistics script excludes it by default.
If you are actually investigating checkpoint behaviour, the interesting evidence lives elsewhere: SLEEP_BPOOL_FLUSH (checkpoint throttling itself), data-file write latency, and the databases’ TARGET_RECOVERY_TIME settings.
Common Causes
- Normal instance operation; the checkpoint process always exists and mostly waits.
- Long stretches between automatic checkpoints on quiet databases.
What To Do
- Filter it out of wait analysis; there is nothing to tune through it.
- For checkpoint performance questions, measure write bursts and latency during checkpoints instead, and consider indirect checkpoints for smoother I/O.
How To See It
Rank waits with Get-WaitStatistics; this one is filtered as noise. In raw DMV output, read past it.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply