PREEMPTIVE_OS_WAITFORSINGLEOBJECT is recorded when a thread calls the Windows WaitForSingleObject function to synchronise with an external client process communicating through that kernel object. In practice it is commonly seen together with ASYNC_NETWORK_IO, depending on the network transport in use between SQL Server and its clients: the same slow-consumer condition can express itself through either wait.
As a preemptive wait, the thread shows RUNNING while Windows holds it.
Is It a Problem?
Read it exactly like ASYNC_NETWORK_IO: the engine produced results and is waiting on the client side to take them. Sustained high values mean client applications are consuming data slowly, row-by-row processing while fetching being the perennial cause, or requesting far more data than they use.
Because the two waits split the same phenomenon by transport, add them together mentally when judging how much “waiting on the app” your instance does.
Common Causes
- Client applications processing results while fetching (RBAR against an open reader).
- Oversized result sets crossing to clients that need a fraction of them.
- Named-pipe or specific transport paths steering the wait here rather than to
ASYNC_NETWORK_IO. - Genuinely slow client hosts or app-side resource starvation.
What To Do
- Identify the waiting sessions and their client applications (
sys.dm_exec_sessionshost and program names). - Fix the consumption pattern: fetch everything promptly then process, and select only needed rows and columns.
- Follow the full
ASYNC_NETWORK_IOplaybook; it applies verbatim.
How To See It
Rank it against everything else with Get-WaitStatistics, summed with ASYNC_NETWORK_IO for the true client-wait picture.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO Wait Type.
Leave a Reply