我们有一个使用Entity Framework 4.0的ASP.NET MVC4应用程序。当我们在生产服务器上部署时,CPU会在一段时间(~2-5h)之后上升,直到接近100%。记忆也会上升到最大值。一段时间后,由于内存很高,应用程序池将自动重置。
服务器:Windows 2008 R2 Standard SP1 IIS:7(V 7.5.7600.16385) 只有一个应用程序池和一个Web应用程序正在运行。
线程的调试诊断工具的堆栈跟踪占用了大部分CPU:
SNIReadSyncOverAsync(SNI_ConnWrapper*, SNI_Packet**, Int32)
.SNIReadSyncOverAsync(SNI_ConnWrapper*, SNI_Packet**, Int32)
System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)
System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)
ntdll!NtWaitForSingleObject
KERNELBASE!WaitForSingleObjectEx
System_Data!SNIReadSyncOverAsync
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_ni!load_config_used
System_Data_Entity_ni
System_Data_Entity_ni
System_Data_Entity_ni
System_Data_Entity_ni
System_Core_ni
System_Core_ni
0x000007fe`99223112
0x000007fe`99222a88
0x000007fe`99222899
0x000007fe`992205cb
0x000007fe`99355596
System_Web_Mvc_ni+138058
System_Web_Mvc_ni+13ca67
System_Web_Mvc_ni+13e71c
System_Web_Mvc_ni+13ca03
System_Web_Mvc_ni+13d175
System_Web_Mvc_ni+13cbe9
System_Web_Mvc_ni+1431df
System_Web_Mvc_ni+13dade
System_Web_Mvc_ni+14f5fe
System_Web_Mvc_ni+13b0ef
System_Web_Mvc_ni+14f514
System_Web_ni
System_Web_ni
System_Web_ni
System_Web_ni
System_Web_ni
System_Web_ni
System_Web_ni
System_Web_ni
clr!UMThunkStub
webengine4!W3_MGD_HANDLER::ProcessNotification
webengine4!W3_MGD_HANDLER::DoWork
webengine4!RequestDoWork
webengine4!CMgdEngHttpModule::OnExecuteRequestHandler
iiscore!NOTIFICATION_CONTEXT::RequestDoWork
iiscore!NOTIFICATION_CONTEXT::CallModulesInternal
iiscore!NOTIFICATION_CONTEXT::CallModules
iiscore!W3_CONTEXT::DoWork
iiscore!W3_CONTEXT::IndicateCompletion
webengine4!MgdIndicateCompletion
System_Web_ni
System_Web_ni
System_Web_ni
System_Web_ni
clr!UM2MThunk_WrapperHelper
clr!UM2MThunk_Wrapper
clr!Thread::DoADCallBack
clr!UM2MDoADCallBack
clr!UMThunkStub
webengine4!W3_MGD_HANDLER::ProcessNotification
webengine4!ProcessNotificationCallback
clr!UnManagedPerAppDomainTPCount::DispatchWorkItem
clr!ThreadpoolMgr::ExecuteWorkRequest
clr!ThreadpoolMgr::WorkerThreadStart
clr!Thread::intermediateThreadProc
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
您知道这个CPU上升的原因是什么?
答案 0 :(得分:0)
嘿,我使用大量的线程时间与SNIReadSyncOverAsync
有完全相同的问题(我发现这是使用DebugDiag)。
我不知道这是否会对其他人有所帮助,但看起来我们的问题出在我们使用的Azure数据库服务器上。我们将它设置为只有50个DTU,最多有100个并发请求。
基本上SNIReadSyncOverAsync
是如此之大,因为Web服务器必须坐在那里等待来自DB服务器的响应,并且DB服务器一次只能处理100个请求,因此Web服务器最终等待很长时间(导致100%的CPU使用率和无法访问的网站)。这可能会出现最近网络流量的增加(例如:如果你们最近购买了广告并且看到你的网络流量大幅增加,现在100个并发请求都不够)
因此,如果您喜欢我们并且您正在使用Azure DB,请检查您的DTU%使用情况。如果它真的很高(80-90%等)尝试将它增加到两倍甚至四倍(这可能是昂贵的!)。我们从弹性标准"弹性标准" (50个eDTU)到标准S4" (400 DTU)我们还没有看到CPU使用率达到100%。事实上,自那以来它一直漂浮在7-9%左右。