Всичко, което задейства повторно компилиране (промяна на web.config, промяна на app_offline.htm, .aspx файл и т.н.), води до максимално използване на процесора в ядрото. Ако повторите процеса, той увеличава използването на процесора на следващото ядро, докато общото използване на процесора достигне 100%.
Свързах windbg с sos разширения и изглежда, че за всяко максимално изчерпано ядро има 1 нишка, заседнала в System.AppDomain.Unload(System.AppDomain) и друга заседнала в Oracle.DataAccess.Client.OracleTuningAgent.DoScan().
Първа нишка
- Oracle.DataAccess.Client.OracleTuningAgent.DoScan()
- Oracle.DataAccess.Client.OracleTuningAgent.TuningFunction()
- System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
- System.Threading.ThreadHelper.ThreadStart()
Втора нишка
- System.AppDomain.Unload(System.AppDomain)
- System.Web.HttpRuntime.ReleaseResourcesAndUnloadAppDomain(System.Object)
- System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
- System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(System.Threading. _ThreadPoolWaitCallback)
- System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(System.Object)
Изглежда, че AppDomain.Unload чака OracleTuningAgent.DoScan да завърши, но тази нишка е блокирана или спяща.
Oracle потвърди проблема (бъг # 9648040) и той е основен приоритет. Междувременно възможните заобиколни решения са:
- Връщане към 11gR1/по-ранен клиент
- Добавете „Self Tuning=false“ към низа за връзка. Разбира се, ще загубите предимствата на автоматичната настройка.
-Скот
