Cualquier cosa que desencadene una recompilación (cambio de web.config, app_offline.htm, cambio de archivo .aspx, etc.) hace que el uso de la CPU en el núcleo llegue al máximo. Si repite el proceso, maximiza el uso de la CPU en el siguiente núcleo, hasta que el uso general de la CPU sea del 100 %.
Conecté windbg con extensiones sos y parece que para cada núcleo al máximo hay 1 subproceso atascado en System.AppDomain.Unload(System.AppDomain) y otro atascado en Oracle.DataAccess.Client.OracleTuningAgent.DoScan().
Primer hilo
- 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()
Segundo hilo
- Sistema.Dominio de aplicación.Descargar(Sistema.Dominio de aplicación)
- 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)
Parece que AppDomain.Unload está esperando que finalice OracleTuningAgent.DoScan, pero ese subproceso está bloqueado o inactivo.
Oracle ha confirmado el problema (error n.° 9648040) y es una prioridad máxima. Mientras tanto, las posibles soluciones son:
- Volver a 11gR1/cliente anterior
- Agregue 'Self Tuning=false' a la cadena de conexión. Por supuesto, perderá los beneficios de la sintonización automática.
-Scott
