Wszystko, co wyzwala ponowną kompilację (zmiana web.config, app_offline.htm, zmiana pliku .aspx itp.) powoduje maksymalne wykorzystanie procesora przez rdzeń. Jeśli powtórzysz proces, maksymalizuje użycie procesora na następnym rdzeniu, aż całkowite użycie procesora wyniesie 100%.
Podłączyłem windbg z rozszerzeniami sos i wygląda na to, że dla każdego wymaksowanego rdzenia jest 1 wątek utknął w System.AppDomain.Unload(System.AppDomain) i inny utknął w Oracle.DataAccess.Client.OracleTuningAgent.DoScan().
Pierwszy wątek
- 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()
Drugi wątek
- 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)
Wygląda na to, że AppDomain.Unload czeka na OracleTuningAgent.DoScan na zakończenie, ale ten wątek jest zablokowany lub śpi.
Oracle potwierdził problem (błąd nr 9648040) i jest to najwyższy priorytet. W międzyczasie możliwe obejścia to:
- Wróć do 11gR1/wcześniejszego klienta
- Dodaj 'Self Tuning=false' do ciągu połączenia. Oczywiście stracisz korzyści płynące z automatycznego dostrajania.
-Scott
