SNI_TASK_COMPLETION is recorded when a thread waits for tasks to finish during a NUMA node state change, specifically around creating a new SNI network listener after a NUMA node comes online. SQL Server distributes connection listeners across NUMA nodes, and topology changes mean listener work.
NUMA node state changes are rare events (startup, hot-add scenarios, certain reconfigurations), and this wait lives only in those moments.
Is It a Problem?
No; it has not been a contention point, and most instances accrue almost none of it outside startup. Its presence marks topology events rather than any performance condition.
If NUMA configuration itself is your topic (soft-NUMA choices, core licensing shapes), the relevant evidence is sys.dm_os_nodes and startup messages in the error log, not this wait.
Common Causes
- Instance startup bringing listeners up across NUMA nodes.
- Rare online NUMA topology changes.
What To Do
- Filter it out of wait analysis.
- Verify NUMA layout through
sys.dm_os_nodeswhen topology is the actual question.
How To See It
Rank waits with Get-WaitStatistics; expect near-zero outside startup windows.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO Wait Type.
Leave a Reply