Alt, hvad der udløser en rekompilering (web.config-ændring, app_offline.htm, .aspx-filændring, osv.) får CPU-bruget på kernen til at maks. Hvis du gentager processen, maksimerer den CPU-forbruget på den næste kerne, indtil det samlede CPU-forbrug er på 100%.
Jeg tilsluttede windbg med sos-udvidelser, og det ser ud til, at der for hver maxed-out kerne sidder 1 tråd fast i System.AppDomain.Unload(System.AppDomain) og en anden sidder fast på Oracle.DataAccess.Client.OracleTuningAgent.DoScan().
Første tråd
- 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()
Anden tråd
- 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)
Det ser ud til, at AppDomain.Unload venter på OracleTuningAgent.DoScan for at blive færdig, men den tråd er blokeret eller i dvale.
Oracle har bekræftet problemet (fejl # 9648040), og det er en topprioritet. I mellemtiden er de mulige løsninger:
- Rul tilbage til 11gR1/tidligere klient
- Tilføj 'Self Tuning=false' til forbindelsesstrengen. Du vil selvfølgelig miste fordelene ved den automatiske tuning.
-Scott