DebugDiag сообщает, что поток слишком часто вызывает GC.Cleanup. Какой процесс породил этот поток?

Question

Я использую Windows 2008 R2 и процессор на 100%. Я запустил DebugDiag в ответственном пуле приложений и обнаружил следующий стек вызовов:

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()

Мой вопрос заключается в том, что я хотел бы выяснить, какой компонент породил этот поток, чтобы я знал, является ли этот поток из приложения Telerik, или он контролируется чем-то, что было создано одним из наших разработчиков.

Как я могу определить, какой объект породил этот поток?

Answer 1

Этот поток порождается средой выполнения OpenAccess.

OpenAccess поддерживает пул соединений с настраиваемым значением "max активных соединений" - по умолчанию 10. Когда все соединения были выданы (параллельные операции), следующий запрос блокируется до тех пор, пока активное соединение не будет возвращено обратно в пул. Если запрос заблокирован, поток управления фоновым пулом пытается принудительно запустить сборку мусора, чтобы освободить все висячие / недействительные соединения, которые могут быть там.

Вы явно указали максимальное активное значение? Может быть, вы должны рассмотреть более высокое значение в зависимости от вашего использования. Есть ли у вас места, где вы получаете доступ к context.Connection и не располагаете им?