我们在azure应用程序服务p2v2示例上有许多api应用程序和webapps。我们已经经历了大量的平台不稳定：应用程序服务变得不健康，我们在各种应用程序（每次都是不同的）中出现了502个错误，这是由于应用程序服务的cpu和内存使用率非常高造成的。我们已经尝试过扩展到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解决了这个问题—这只会在空站点上造成问题—我们还没有机会看到所有站点都已满时性能是否良好。）