这是一个我正在间歇性地遇到的问题，但是当它发生这种情况时，会因为支付我使用它们的客户的巨大不满而取消我的所有应用程序服务 .
今天凌晨4点（当没有人使用任何应用程序时），应用程序服务计划上的CPU从2％上升到100％并一直持续到早上7点左右，当我登录门户并停止所有应用程序服务时：
从上面的图片中可以看出，跳转似乎与新实例的存在重合 - 图表上方有两个RD000 ...标签 . 这是否意味着Azure已经启动了一个新的实例/服务器并将我的应用程序移到了它上面？我没有将Scale Out设置为自动缩放，因此我的应用程序应该只存在于一个实例上 .
如果是这种情况，那么我的应用程序（一个计划中只有8个）必须再次“热身”并以某种方式卡在100％？
如果我停止每个应用程序，然后慢慢打开一个应用程序，然后一切都开始工作，但如果我太快打开它们，那么它们最终再次以100％挂钩 .
这也在白天随机发生（尽管通常只有一个应用程序） . 以下是当天晚些时候其中一个应用程序的CPU图表示例：
同样，如果我停止应用程序然后再次启动它，一旦加载它就会按预期运行 .
该应用程序是一个ASP.NET MVC4应用程序，NHibernate作为Azure SQL数据库的ORM，它使用Redis作为其会话状态提供程序 . 它没有运行webjobs .
我完全不知道如何找出这些问题的原因 .
Update
根据David的建议，我下载了一个转储，当它挂在100％时，我现在正在尝试使用WinDbg进行调试 .
所以我正在加载X86版本的WinDbg，因为我的webapp平台设置为32位 . 我不能用
!loadby sos clr
因为它正在寻找D：\驱动器中的文件 - 我假设因为转储来自Azure VM，其中应用程序映射到D：\ - 所以我正在使用：
!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>
----------------------------------------------------------------------------
然后我尝试跑步！失控，抱怨：
ERROR: !runaway: extension exception 0x80004002.
"Unable to get thread times - dumps may not have time information"
Kudu是否会在没有线程时间的情况下生成转储，或者我做错了什么？我试过谷歌搜索问题，但大多数建议建议将dbghelp.dll复制到与procdump相同的文件夹，这显然是我无法做到的 .
Update 2 (30 Mar)
因此，CPU在今天凌晨4点左右再次上涨至100％，并留在那里 . 当我登录并进行转储时，我注意到它似乎不是正在咀嚼CPU的w3wp.exe进程，而是两个VBCSCompiler进程：
该应用程序是我正在使用msbuild部署的MVC应用程序，因此我只能假设VBCSCompiler正在编译App_Code中的视图和文件 . 当我停止每个站点并将它们全部交错启动时，让每个站点都有时间加载，一切正常，但同时启动它们，整个事情锁定在100％CPU中 . 我有两个问题：
-
如何弄清楚VBCSCompiler卡在100％的原因是什么？
-
有没有办法在部署之前用msbuild编译视图，这样就不需要VBCSCompiler了？
1 回答
App Service会偶尔将应用程序移动到其他VM，例如在进行平台升级时 .
这可以解释一个短暂的冷启动，但你所描述的是一个3小时的情况，CPU固定在100％，并且有更严重的事情导致这种情况 . 我的猜测是，由于某种原因，你的应用程序陷入了无限的CPU外观 .
调查此问题的最佳方法是下载流程的完整转储，并在本地进行分析 .