DebugDiag reports a thread is calling GC.Cleanup too often. What process spawned that thread?

Question

I'm using Windows 2008 R2 and the CPU is at 100%. I ran DebugDiag on the app pool that is responsible and discovered the following call stack:

System.GC._Collect(Int32, Int32)
OpenAccessRuntime.Relational.conn.RelationalConnectionPool.CleanupLeftOvers(System.Object)
System.Threading.ExecutionContext.runTryCode(System.Object)
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
System.Threading.ThreadPoolWorkQueue.Dispatch()
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

My question is that I'd like to figure out what component spawned this thread so I know if this thread is from the Telerik application, or if it's controlled by something one of our developers created.

How can I determine what object spawned this thread?

score 2 · Answer 1 · answered Oct 10 '12 at 15:46

This thread is spawned by the OpenAccess runtime.

OpenAccess maintains a connection pool with a configurable 'max active connections' value - default of 10. When all connections have been given out (parallel operations) the next request blocks till the time an active connection is returned back to the pool. If a request is blocked, a background pool management thread tries to enforce a garbage collection to free any dangling/invalid connections that might be there.

Have you explicitly specified a max active value? Maybe you should consider a higher value based on your usage. Do you have places where you access the 'context.Connection' and do not dispose it?

DebugDiag reports a thread is calling GC.Cleanup too often. What process spawned that thread?

1 Answers1