LOGBUFFER Wait Type in SQL Server

---

LOGBUFFER occurs when a session generating log records has to wait for free space in a log buffer. SQL Server stages log records in small in-memory log buffers (up to 60KB each) before flushing them to the log file; when the buffers are all full because flushes cannot keep up with the rate of log generation, new log records queue here.

It often travels with WRITELOG. Think of LOGBUFFER as pressure before the flush (no room to even stage the record), while WRITELOG is the commit waiting for its flush to hit disk. Both point down the same pipe.

Is It a Problem?

Some activity is normal on write-intensive OLTP systems. It deserves focus when LOGBUFFER is consistently high alongside WRITELOG, because that combination means the log pipeline is saturated end to end: records queue to get into buffers, and buffers queue to get onto disk.

Common Causes

• Log flush latency: a slow log drive backs everything up, keeping the buffers full.
• Very high log generation rates, mass modifications producing records faster than the disk can drain them.
• Log file sharing storage with data files or tempdb, so flushes queue behind unrelated I/O.

What To Do

1. Measure log write latency per log file in sys.dm_io_virtual_file_stats; write stalls above a few milliseconds make this whole wait family worse.
2. Reduce log volume where design allows: batch small commits, avoid churning indexes needlessly, use minimally logged operations for bulk work.
3. Put the log on dedicated low-latency storage; log writes are latency-sensitive and hate sharing.
4. For workloads that can tolerate a small durability window, delayed durability (DELAYED_DURABILITY) removes the commit-time flush wait entirely; understand the data-loss trade before using it.

How To See It

Rank it with Get-WaitStatistics. If LOGBUFFER and WRITELOG both rise, investigate the full transaction log pipeline.

---