Category: Wait Types

SOS_MEMORY_TOPLEVELBLOCKALLOCATOR is recorded when a thread waits for the critical section inside the memory allocator that steals memory from the buffer pool, the path used when components need large memory blocks that come out of the buffer pool’s share. One thread at a time gets to run that allocation code; bursts of large allocations queue…

SOS_PHYS_PAGE_CACHE is a wait on the mutex a thread must hold before allocating physical memory pages from Windows or returning them. It shows up on instances using locked pages in memory, that is, when the service account holds the SeLockMemoryPrivilege right (Lock Pages in Memory), because that allocation path goes through this guarded cache. Seeing…

SOS_SYNC_TASK_ENQUEUE_EVENT is recorded when a task is started synchronously: the starting thread enqueues the task on an SOS node and waits for it to actually begin running (or for the enqueue to time out). Most task starts in SQL Server are asynchronous, control returns immediately once the request is queued, so the synchronous variant is…

SOS_WORK_DISPATCHER is recorded by a SQLOS worker thread that has become idle and is waiting to be handed something to do. The wait starts when the thread runs out of work and ends when the dispatcher assigns it a task. It arrived with scheduling improvements in SQL Server 2019 and is ever-present on Azure SQL…

SOS_WORKER_MIGRATION appears to track a worker (thread) being moved to a different scheduler. It arrived with SQL Server 2019’s scheduling improvements, which allow a worker at the head of one scheduler’s runnable queue to migrate to another scheduler within the same NUMA node, smoothing out imbalances where one scheduler queues work while a neighbour idles.…

SP_SERVER_DIAGNOSTICS_SLEEP is recorded by the background system health monitor thread while it sleeps between runs of sp_server_diagnostics, the built-in health check procedure added in SQL Server 2012 to power automatic failure detection for Availability Groups and failover clusters. The procedure runs on a fixed cadence; this wait is the gap between runs. Every instance from…

SQLCLR_APPDOMAIN is recorded while CLR execution waits for an application domain to complete startup. SQL Server hosts .NET code in appdomains (one per database/owner combination, broadly), and the first CLR call after an appdomain has been created, or recreated, pays the startup cost. Sessions arriving during that startup wait here. Steady state, appdomains stay loaded…

SQLCLR_ASSEMBLY is recorded while a thread waits for access to the list of loaded assemblies in an appdomain. When CLR code runs, the host tracks which assemblies are loaded per domain, and threads consulting or updating that list briefly serialise on it. It is bookkeeping inside the CLR hosting layer, adjacent to SQLCLR_APPDOMAIN in the…

Four waits cover SQL Trace’s file-writing machinery, and they share one story, so this page covers the set: Since the default trace runs on practically every instance, small amounts of the family are universal. Are They a Problem? Rarely; none has been a noticeable contention point. The family scales with trace activity: the default trace’s…