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.
LOGMGR_QUEUE is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply