azure - 什么会导致 Azure 应用服务计划中的高 KUDU 使用率（以及最终的 502 错误）？

Question

我们在 Azure App Service P2v2 实例上有许多 API 应用程序和 WebApps。我们一直在经历大量的平台不稳定：应用服务变得不健康，并且由于应用服务上的 CPU 和内存使用率非常高，我们在各种应用（每次不同的应用）中出现了一系列 502 错误。我们已经尝试一直扩展到 P3v2，但无论问题是什么，似乎最终都会消耗所有可用资源。

每当我们能够在应用程序中追查到罪魁祸首时，它就会证明不是应用程序本身，而是与之相关的 Kudu 服务。

一个示例错误消息是High physical memory usage detected on multiple occasions. The kudu process for the app [sitename]'pe-services-color' is the most common cause of high memory usage. The most common cause of high memory usage for the kudu process is web jobs.其 Kudu 服务命名的实际应用程序经常更改。

什么可能导致 Kudu 服务消耗如此多的 CPU/内存，我们可以做些什么来稳定这个应用服务？

仅仅是因为我们有太多的应用程序在一个计划上运行吗？这似乎不太可能，因为所有这些应用程序以前都在单个经典云服务实例上运行，但如果是这样，单个计划中的应用程序和插槽有什么限制？

（我看过这个问题，但答案没有帮助）

更新 来自 Azure 支持，这些显然是对小型 - 中型 - 大型非共享应用程序服务的限制：

工人规模最大站点

小5中10大20

• “站点”包括应用程序服务/api 应用程序及其插槽。

它们看起来低得离谱，并且使较大的应用服务单元非常不经济。谁能确认这些数字？

（顺便说一句，我们发现全面关闭 Always On 解决了这个问题 - 它只是在空站点上引起问题 - 我们还没有机会查看所有站点都填充后性能是否良好。）

标签： azureazure-web-app-serviceazure-app-service-planskudu

Answer 1

高 CPU 和内存利用率主要是由您的程序/代码本身引起的。如果有很多 CPU 密集型任务，并且您应用了大量并行编程来产生大量新线程，则可能会导致高 CPU 和内存利用率。因此，请查看您的代码并查看此类实例。当并行线程的数量增加时，cpu 利用率变高并且它开始频繁扩展，这会增加您的成本，有时也会导致线程丢失和意外结果。由于 Azure 资源成本很高，您需要相应地规划您的性能。您可以使用刀片中的应用服务计划的 Metrics 选项对此进行监控。