DIRTY_PAGE_POLL is recorded by the background task that supports indirect checkpoints while it sleeps between polls looking for dirty pages (modified pages in the buffer pool that need writing to disk). It wakes roughly every 100 milliseconds, checks for work, and goes back to sleep, clocking this wait the entire time it sleeps.
A timer loop that mostly sleeps is exactly what this is, and that is all it is.
Is It a Problem?
No, never. It accumulates at a steady drumbeat on any instance with databases using indirect checkpoints, which is the default for databases created on SQL Server 2016 and later (TARGET_RECOVERY_TIME = 60). On raw sys.dm_os_wait_stats output it can rank surprisingly high purely from uptime; that ranking carries zero information about performance.
There is no threshold, pattern, or combination in which DIRTY_PAGE_POLL itself becomes actionable.
Common Causes
- Databases using indirect checkpoints, i.e. most databases created on modern versions.
- Long uptime letting the 100ms polls accumulate into large totals.
What To Do
- Filter it out of wait analysis with the other benign background waits; our
Get-WaitStatisticsscript does this by default. - If you are actually investigating checkpoint behaviour, look at
SLEEP_BPOOL_FLUSH, data-file write latency, and theTARGET_RECOVERY_TIMEsetting per database instead. - Resist the urge to “fix” it by switching back to automatic checkpoints; indirect checkpoints are the better default, and this wait is not a cost.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered out as noise. If you query the DMV raw, you now know to read straight past it.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply