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.
The wait exists largely so those migrations are observable.
Is It a Problem?
No; it has not been a contention point, and its presence documents the load-balancing working. Migration counts scale with how uneven the scheduler load momentarily gets, which busy OLTP systems produce naturally.
Genuine scheduler pressure still reads through the classic signals: SOS_SCHEDULER_YIELD and signal wait time for CPU contention, runnable task counts in sys.dm_os_schedulers for queuing. Worker migration is the engine’s mitigation, not the symptom.
Common Causes
- SQL Server 2019+ balancing workers across schedulers within NUMA nodes under variable load.
What To Do
- Filter it out of wait analysis.
- Assess CPU pressure through the established signals; migrations are the scheduler helping, not hurting.
How To See It
Rank waits with Get-WaitStatistics; expect modest background presence on busy 2019+ instances.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply