CLR_SEMAPHORE is recorded when a task executing CLR code waits to acquire a semaphore, one of the synchronisation primitives CLR threads use to gate access to limited resources. Like its sibling CLR_AUTO_EVENT, it comes with the territory of CLR integration being active, whether through user assemblies or the engine’s own internal CLR usage.
Most instances show it as background residue rather than anything a workload would feel.
Is It a Problem?
Usually not; it sits on the benign filter list and has not been a contention point in ordinary operation. The scenario where it earns attention is heavy custom CLR usage: if your assemblies gate work behind semaphores and a thread can hold the gated resource for a long time, this wait becomes a mirror of that design, and growth here tracks contention inside your .NET code, not inside SQL Server.
That makes it a code review prompt, not a server tuning prompt.
Common Causes
- Normal CLR integration background behaviour.
- Custom assemblies serialising access to limited resources (connections, files, buffers) via semaphores.
- A CLR routine holding a gated resource longer than intended.
What To Do
- Filter it from routine analysis; our
Get-WaitStatisticsscript excludes it by default. - If it grows on an instance with substantial custom CLR, profile the assemblies: what the semaphores guard and how long holders keep them.
- Keep long-running external work out of gated CLR sections; the same hygiene as any lock-holding code.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered. Read growth as a property of your CLR code, and investigate there.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply