Tutto ciò che attiva una ricompilazione (modifica web.config, app_offline.htm, modifica del file .aspx, ecc.) Fa sì che l'utilizzo della CPU sul core venga massimizzato. Se ripeti il processo, massimizza l'utilizzo della CPU sul core successivo, fino a quando l'utilizzo complessivo della CPU non raggiunge il 100%.
Ho collegato windbg con le estensioni sos e sembra che per ogni core al massimo ci sia 1 thread bloccato in System.AppDomain.Unload(System.AppDomain) e un altro bloccato su Oracle.DataAccess.Client.OracleTuningAgent.DoScan().
Primo 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()
Secondo 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)
Sembra che AppDomain.Unload sia in attesa di completamento di OracleTuningAgent.DoScan, ma quel thread è bloccato o inattivo.
Oracle ha confermato il problema (bug n. 9648040) ed è una priorità assoluta. Nel frattempo, le possibili soluzioni alternative sono:
- Torna a 11gR1/client precedente
- Aggiungi 'Self Tuning=false' alla stringa di connessione. Ovviamente perderai i vantaggi della sintonizzazione automatica.
-Scott
