PREEMPTIVE_OS_FLUSHFILEBUFFERS is recorded while a thread calls the Windows FlushFileBuffers function (or its equivalent on Linux), which forces everything buffered for a file down to durable media. Like all preemptive waits, the thread runs outside SQL Server’s scheduler until the OS call returns.
Its claim to fame is SQL Server on Linux: from SQL Server 2017 CU6 onward, the Linux engine forcibly flushes log blocks and data pages to guarantee durability, and this wait is routinely the most prevalent on Linux instances as a result.
Is It a Problem?
On Linux, its dominance is expected behaviour, not a fault, and it is generally filtered as benign. The trade is real though: those forced flushes cost write latency. If your I/O subsystem genuinely guarantees write durability (battery-backed cache, enterprise SAN), the forced-flush behaviour can be disabled with trace flag 3979, recovering performance; that is a durability decision to make deliberately with the storage facts in hand.
On Windows, meaningful time here usually tracks operations that explicitly flush files and inherits whatever latency the storage adds.
Common Causes
- SQL Server on Linux’s durability-first flush behaviour (2017 CU6+), the dominant source.
- Slow storage stretching each forced flush.
- File-level operations and certain log-durability paths issuing explicit flushes on Windows.
What To Do
- On Linux: read Microsoft’s guidance on the forced flush behaviour, verify what your storage actually guarantees, and only then consider trace flag 3979.
- Measure write latency (
sys.dm_io_virtual_file_stats); a flush is only as fast as the device honouring it. - On Windows, correlate the wait with the operations generating it before tuning anything; modest background amounts are noise.
How To See It
Rank it against everything else with Get-WaitStatistics. On Linux instances, expect it at the top and judge the storage instead.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply