High waits on CLR_MANUAL_EVENT and CLR_AUTO_EVENT

If you have a SQL CLR application, you may notice that waits on CLR_MANUAL_EVENT and CLR_AUTO_EVENT from sys.dm_os_wait_stats are very high.

This is normal and can be safely ignored because these waits reflect internal CLR runtime waits under normal conditions.  Since SQL as a CLR host implements synchronization mechanism, it is able to track these kinds of waits and exposes them via DMV. 

The only exception when you need to pay attention to these two wait types is that you actually use unsafe assemblies and use CLR Event objects (ManualResetEvent or AutoResetEvent) yourself.  In other words, if you use ManualResetEvent and you code results in waiting on the object, the wait time will also be reflected in CLR_MANUAL_EVENT type.  The same is true for AutoResetEvent which will be reflected in CLR_AUTO_EVENT type.  But using these two objects will require explicitly creating the assembly in unsafe mode.  

To summarize, if all your assemblies are created in safe mode and you see high waits on CLR_MANUAL_EVENT and CLR_AUTO_EVENT, you can safely ignore them.

Jack Li
Escalation Engineer

• Anonymous
  June 19, 2008
  I've was reviewing wait stats the other day and kept finding this wait stat peaking out the other wait

• Anonymous
  November 13, 2008
  I've was reviewing wait stats the other day and kept finding this wait stat peaking out the other wait stats by a few hundred milliseconds. Oh my! Should I care or not... well long story short is that if all of the CLR assemblies are created in safe mode

• Anonymous
  May 31, 2013
  The comment has been removed

• Anonymous
  June 11, 2013
  Note that if you see CLR_MANUAL_EVENT wait from sys.dm_exec_requests, this will cause perf issues. Please apply hotfix support.microsoft.com/default.aspx and look into this blog: blogs.msdn.com/.../a-performance-issue-involving-clr-garbage-collection-and-sql-cpu-affinity-setting.aspx

  • Anonymous
    May 20, 2017
    Is there another way to around this issue? Or just installing a hotfix?

• Anonymous
  December 22, 2014
  I have noticed on a 32 core SQL 2008 R2 server, the server is maxing out at 20 parallel CLR Objects at once, after that we start getting higher and higher CLR_MANUAL_EVENT wait states.  When we are running at less than 20 parallel transactions, the average transaction time is small,  less than 1/10th of a second, once we get past the 20 parallel query mark, the transaction time jumps dramatically.   Is this tied to a thread pool size we can configure?   The server has plenty of CPU/Memory/disk bandwidth.