LOGMGR_QUEUE is recorded by the log writer thread (threads, plural, from SQL Server 2016 onward) while waiting for something to do: either new log to flush or an in-flight write to complete. The log writer is a permanent background resident, and whenever your workload is not committing transactions, it parks here.
It is one of the most recognisable benign waits in the DMV, present near the top of raw output on virtually every instance ever built.
Is It a Problem?
No, and it is worth being precise about why, because its name makes people think of WRITELOG. LOGMGR_QUEUE is the log writer idle; WRITELOG is your transactions waiting for the log writer. The first is the absence of log pressure; the second is the presence of it. High LOGMGR_QUEUE totals mean the log writer spent lots of time with nothing to flush, which is either a quiet workload or a fast log disk keeping the queue drained.
There is no scenario where this wait itself is actionable.
Common Causes
- The instance being up; the log writer always exists and often waits.
- Quiet or read-heavy workloads generating little log.
- Multiple log writer threads (2016+) each accumulating idle time.
What To Do
- Filter it out; our
Get-WaitStatisticsscript excludes it by default. - For log pressure questions, look at
WRITELOGandLOGBUFFERplus log-file write latency; this wait contributes nothing. - If a report or tool ranks it as a top wait, treat that as a filtering gap, not a finding.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered as background noise.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply