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.
SNI_CRITICAL_SECTION is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply