Azure App Services突然占用100%CPU

lit*_*rva 7 azure azure-web-sites

这是我间歇性遇到的一个问题,但是一旦发生,它就会使我的所有应用程序服务崩溃,这让付费给我使用它们的客户大为不悦。

今早凌晨4点(没有人使用任何应用程序时),应用程序服务计划中的CPU从2%跃升至100%,并一直呆在那里直到我早上7点左右登录门户并停止所有应用程序服务:

总体 实例1 实例2

从上图可以看到,跳转似乎与新实例的存在相吻合-图形上方有两个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中。我有两个问题:

  1. 如何找出VBCSCompiler卡在100%的原因是什么?

  2. 有没有一种方法可以在部署之前使用msbuild编译视图,因此不需要VBCSCompiler?

Dav*_*bbo 5

App Service确实会偶尔将应用程序移动到其他VM,例如,在进行平台升级时。

这可以解释一个短暂的冷启动,但是您所描述的是3个多小时的情况,CPU固定为100%,并且发生这种情况的情况要严重得多。我的猜测是由于某种原因,您的应用陷入了无限CPU循环。

对此进行调查的最佳选择是下载该过程的完整转储,并在本地进行分析。