lit*_*rva 7 azure azure-web-sites
这是我间歇性遇到的一个问题,但是一旦发生,它就会使我的所有应用程序服务崩溃,这让付费给我使用它们的客户大为不悦。
今早凌晨4点(没有人使用任何应用程序时),应用程序服务计划中的CPU从2%跃升至100%,并一直呆在那里直到我早上7点左右登录门户并停止所有应用程序服务:
从上图可以看到,跳转似乎与新实例的存在相吻合-图形上方有两个RD000 ...选项卡。这是否意味着Azure已启动了一个新实例/服务器并将其应用程序移至该实例/服务器?我没有将“横向扩展”设置为自动缩放,因此我的应用程序应仅存在于一个实例上。
如果真是这样,那么我的应用程序(一个计划中只有8个)是否必须再次“热身”并且以某种方式卡在100%的位置上?
如果我停止了每个应用程序,然后一次缓慢地打开它们,那么一切都会再次开始工作,但是如果我打开它们太快,它们最终将以100%的速度固定。
这在一天中也随机发生(尽管通常只有一个应用程序)。这是当天晚些时候其中一个应用的CPU图形的示例:
同样,如果我停止了该应用程序然后再次启动它,则在加载后,它会按预期运行。
该应用程序是一个ASP.NET MVC4应用程序,其中NHibernate作为其对Azure SQL DB的ORM,并且正在使用Redis作为其会话状态提供程序。它没有运行的webjobs。
我对如何确定这些问题的原因完全不知所措。
更新资料
根据下面David的建议,我下载了一个转储,当时它以100%固定,现在我正尝试使用WinDbg对其进行调试。
因此,我将Webapp的Platform设置为32bit时,正在加载WinDbg的X86版本。我不能用
!loadby sos clr
Run Code Online (Sandbox Code Playgroud)
在寻找D:\驱动器中的文件时-我认为是因为转储来自将应用程序映射到D:\的Azure VM,所以我使用的是:
!load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll
Run Code Online (Sandbox Code Playgroud)
告诉我:
----------------------------------------------------------------------------
The user dump currently examined is a minidump. Consequently, only a subset
of sos.dll functionality will be available. If needed, attaching to the live
process or debugging a full dump will allow access to sos.dll's full feature set.
To create a full user dump use the command: .dump /ma <filename>
----------------------------------------------------------------------------
Run Code Online (Sandbox Code Playgroud)
然后我尝试运行!runaway,它抱怨:
ERROR: !runaway: extension exception 0x80004002.
"Unable to get thread times - dumps may not have time information"
Run Code Online (Sandbox Code Playgroud)
是Kudu产生没有线程时间的转储,还是我做错了什么?我已经尝试过搜索该问题,但是大多数建议都建议将dbghelp.dll复制到与procdump相同的文件夹中,这显然是我做不到的。
更新2(3月30日)
因此,今天早上约凌晨4点,CPU再次跳至100%,并停留在那里。当我登录并执行转储时,我注意到似乎不是在咀嚼CPU的w3wp.exe进程,而是两个VBCSCompiler进程:
该应用程序是我使用msbuild部署的MVC应用程序,因此我只能假定VBCSCompiler正在编译App_Code中的视图和文件。当我停止每个站点并交错启动它们,给每个站点加载时间时,一切正常,但是同时启动它们,整个过程都锁定在100%CPU中。我有两个问题:
如何找出VBCSCompiler卡在100%的原因是什么?
有没有一种方法可以在部署之前使用msbuild编译视图,因此不需要VBCSCompiler?
App Service确实会偶尔将应用程序移动到其他VM,例如,在进行平台升级时。
这可以解释一个短暂的冷启动,但是您所描述的是3个多小时的情况,CPU固定为100%,并且发生这种情况的情况要严重得多。我的猜测是由于某种原因,您的应用陷入了无限CPU循环。
对此进行调查的最佳选择是下载该过程的完整转储,并在本地进行分析。
| 归档时间: |
|
| 查看次数: |
1743 次 |
| 最近记录: |