Alles, was eine Neukompilierung auslöst (web.config-Änderung, app_offline.htm, .aspx-Dateiänderung usw.), führt dazu, dass die CPU-Auslastung auf dem Kern maximal wird. Wenn Sie den Vorgang wiederholen, wird die CPU-Auslastung auf dem nächsten Kern maximiert, bis die Gesamt-CPU-Auslastung bei 100 % liegt.
Ich habe windbg mit sos-Erweiterungen verbunden und es sieht so aus, als ob für jeden ausgereizten Kern 1 Thread in System.AppDomain.Unload (System.AppDomain) und ein weiterer in Oracle.DataAccess.Client.OracleTuningAgent.DoScan() hängen bleibt.
Erster Thread
- 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()
Zweiter Thread
- 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)
Es sieht so aus, als ob AppDomain.Unload darauf wartet, dass OracleTuningAgent.DoScan beendet wird, aber dieser Thread ist blockiert oder schläft.
Oracle hat das Problem bestätigt (Bug # 9648040) und es hat höchste Priorität. In der Zwischenzeit sind die möglichen Problemumgehungen:
- Zurück zu 11gR1/früherem Client
- Fügen Sie 'Self Tuning=false' zur Verbindungszeichenfolge hinzu. Die Vorteile des automatischen Tunings gehen dabei natürlich verloren.
-Scott
