Azure应用程序服务计划中有两个应用程序的内存使用率为100%——工作集使用10gb+；

我有一个14gb内存的应用程序服务计划——它应该足够满足我的应用程序的需要。有两个应用程序服务在其上运行，每个应用程序服务都是相同的——它们的私有内存消耗量徘徊在1gb左右，但在高使用率期间可能达到4gb。一个应用程序的使用模式比另一个应用程序更重

最近，在高使用率期间，我注意到被大量使用的服务可能会变得无响应，并且在应用程序服务计划中，内存使用率保持在100%

高流量服务正在使用4gb的私有内存，并开始大幅减速。当我转到/scm…/ProcessExplorer/页面时，我可以看到低流量服务使用了1gb的私有内存和10gb的“工作集”

据我所知，至少在一台机器上，当另一个进程需要内存时，应该释放工作集。当两个应用程序服务共享一个计划时，这种情况会自然发生吗

在我看来，低流量实例上的工作集并没有被释放以满足高流量应用程序服务的需求

---

如果确实如此，那么简单的解决方法就是将它们转移到单独的应用程序服务计划中，每个计划都有7gb的内存。然而，这似乎可能只是在转移问题——是否有其他人注意到在单个应用程序服务计划中多个应用程序存在类似问题？据我所知，它们不应该相互干扰，以至于它们都需要分开。还是我得到了错误的诊断？

在某些高内存消耗的情况下，您的应用可能确实需要更多的计算资源。在这种情况下，考虑扩展到更高的服务层，以便应用程序获得它需要的所有资源。其他时候，代码中的错误可能会导致内存泄漏。编码实践也可能会增加内存消耗。了解是什么触发了高内存消耗是一个分为两部分的过程。首先，创建一个进程转储，然后分析进程转储。Azure站点扩展库中的崩溃诊断程序可以有效地执行这两个步骤。了解更多信息

---

参考

最后，我们通过缓解措施解决了这个问题，而不是找到根本原因

几个月前，我们找到了一个缓解以前内存问题的策略，就是每晚使用powershell脚本重新启动服务器。这似乎可以防止内存随着时间的推移而积累，只需花费几秒钟的停机时间。由于我们的用户都位于同一地理位置，所以我们的系统不会有太多夜间流量

然而，我们最近发现，夜间重启报告“成功”，但实际上由于凭据过期，每晚都失败。这意味着，在我发布的问题中，我们遇到的内存问题实际上因服务器数周的正常运行而加剧。恢复隔夜重启解决了我们所看到的内存问题，而且我们肯定再也看不到我们的系统使用10gb+了

如果他们再次抬头，我们将调查记忆问题。KetanChawda MSFT关于使用内存转储分析内存使用情况的建议将在需要时用于本次调查