Tout ce qui déclenche une recompilation (modification de web.config, app_offline.htm, modification de fichier .aspx, etc.) entraîne une utilisation maximale du processeur sur le cœur. Si vous répétez le processus, il maximise l'utilisation du processeur sur le cœur suivant, jusqu'à ce que l'utilisation globale du processeur soit à 100 %.
J'ai connecté windbg avec des extensions sos et il semble que pour chaque cœur au maximum, il y ait 1 thread bloqué dans System.AppDomain.Unload(System.AppDomain) et un autre bloqué sur Oracle.DataAccess.Client.OracleTuningAgent.DoScan().
Premier fil
- 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()
Deuxième fil
- 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)
Il semble que AppDomain.Unload attend qu'OracleTuningAgent.DoScan se termine, mais ce thread est bloqué ou en veille.
Oracle a confirmé le problème (bug # 9648040) et il s'agit d'une priorité absolue. En attendant, les solutions de contournement possibles sont :
- Revenir à 11gR1/ancien client
- Ajoutez 'Self Tuning=false' à la chaîne de connexion. Vous perdrez bien sûr les avantages du réglage automatique.
-Scott
