Alles dat een hercompilatie activeert (web.config-wijziging, app_offline.htm, .aspx-bestandswijziging, enz.) zorgt ervoor dat het CPU-gebruik in de kern maximaal is. Als u het proces herhaalt, wordt het CPU-gebruik op de volgende kern maximaal, totdat het algehele CPU-gebruik 100% is.
Ik heb windbg aangesloten met sos-extensies en het lijkt erop dat voor elke maximale kern er 1 thread vastzit in System.AppDomain.Unload (System.AppDomain) en een andere vastzit op Oracle.DataAccess.Client.OracleTuningAgent.DoScan().
Eerste draadje
- 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()
Tweede draad
- 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)
Het lijkt erop dat AppDomain.Unload wacht op OracleTuningAgent.DoScan om te voltooien, maar die thread is geblokkeerd of slaapt.
Oracle heeft het probleem bevestigd (bug # 9648040) en het heeft de hoogste prioriteit. In de tussentijd zijn de mogelijke oplossingen:
- Teruggaan naar 11gR1/eerdere klant
- Voeg 'Self Tuning=false' toe aan de verbindingsreeks. Je verliest natuurlijk de voordelen van de automatische afstemming.
-Scott