SNI_CRITICAL_SECTION is recorded when a thread waits for a critical section inside the SQL Server Network Interface (SNI), the layer that encapsulates TDS packets and talks to clients over the configured transports. Processing communication packets involves shared structures, and threads take brief turns through their guards.
Connection-handling plumbing, active on every instance that has clients.
Is It a Problem?
No; it has not been a contention point, and its normal profile is trace amounts scaling loosely with connection and packet volume. Even connection-storm scenarios express themselves through other signals first (logins per second, THREADPOOL if workers run out, preemptive authentication waits if AD slows).
There is no configuration aimed at this wait; SNI manages its own synchronisation.
Common Causes
- Normal client communication across busy connection workloads.
- Connection churn (open/close storms) raising the packet-processing tempo.
What To Do
- Filter it out of wait analysis.
- For connection-layer problems, look at login rates, connection pool behaviour on the application side, and the error log’s connectivity entries instead.
How To See It
Rank waits with Get-WaitStatistics; expect background traces only.
Part of the SQL Server Wait Types Library.
Related deep dive: ASYNC_NETWORK_IO Wait Type.
Leave a Reply