【发布时间】：2017-03-13 14:08:27
【问题描述】：
这是我间歇性遇到的一个问题，但当它发生时，我的所有应用服务都被关闭了，这让付费使用它们的客户非常不满。
今天凌晨 4 点（当时没有人使用任何应用），应用服务计划中的 CPU 从 2% 跃升至 100% 并一直保持到早上 7 点左右，当时我登录门户并停止了所有应用服务：
从上图中可以看出，跳跃似乎与新实例的存在相吻合 - 图表上方有两个 RD000... 选项卡。这是否意味着 Azure 已经启动了一个新的实例/服务器并将我的应用程序转移到它上面？我没有将 Scale Out 设置为自动缩放，所以我的应用应该只存在于一个实例上。
如果是这样，那么我的应用程序（一个计划中只有 8 个）是否必须再次“预热”并以某种方式卡在 100% 上？
如果我停止每个应用程序，然后一次缓慢地打开它们，那么一切都会重新开始工作，但如果我打开它们太快，那么它们最终会再次固定在 100%。
这也会在白天随机发生（尽管通常只针对一个应用）。以下是当天晚些时候某个应用的 CPU 图表示例：
同样，如果我停止应用程序然后重新启动它，一旦加载它就会按预期运行。
该应用程序是一个 ASP.NET MVC4 应用程序，使用 NHibernate 作为其 ORM 到 Azure SQL DB 并且它使用 Redis 作为其会话状态提供程序。它没有运行任何网络作业。
我完全不知道如何确定这些问题的原因。
更新
根据 David 下面的建议，我下载了一个 100% 的转储文件，现在我正在尝试使用 WinDbg 对其进行调试。
所以我正在加载 X86 版本的 WinDbg，因为我的 webapp 平台设置为 32 位。我不能用
!loadby sos clr
因为它正在寻找 D:\ 驱动器中的文件 - 我假设因为转储来自应用程序映射到 D:\ 的 Azure VM - 所以我使用的是：
!load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll
这告诉我：
----------------------------------------------------------------------------
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>
----------------------------------------------------------------------------
然后我尝试运行 !runaway，它抱怨：
ERROR: !runaway: extension exception 0x80004002.
"Unable to get thread times - dumps may not have time information"
是 Kudu 产生没有线程时间的转储，还是我做错了什么？我试过用谷歌搜索这个问题，但大多数建议建议将 dbghelp.dll 复制到与 procdump 相同的文件夹中，这显然是我做不到的。
更新 2（3 月 30 日）
所以 CPU 在今天凌晨 4 点左右再次跃升至 100% 并保持在那里。当我登录并进行转储时，我注意到它似乎不是 w3wp.exe 进程正在吞噬 CPU，而是两个 VBCSCompiler 进程：
该应用程序是我使用 msbuild 部署的 MVC 应用程序，因此我只能假设 VBCSCompiler 正在编译 App_Code 中的视图和文件。当我停止每个站点并交错启动它们时，让每个站点有时间加载，一切正常，但同时启动它们，整个事情都锁定在 100% 的 CPU 中。我有两个问题：
如何确定 VBCSCompiler 卡在 100% 的原因是什么？
有没有办法在部署之前使用 msbuild 编译视图，从而不需要 VBCSCompiler？
【问题讨论】：
标签： azure azure-web-app-service