【发布时间】：2018-02-07 00:30:49
【问题描述】：
好的，所以我有一个流量非常大的应用程序（每秒大约 17 个请求）。该应用程序是使用 .Net Core 2.0（刚刚升级）构建的 REST API。
该应用托管在 Azure 上，我们遇到了一个看起来像内存泄漏的问题，因为服务器会非常缓慢（超过一周）耗尽所有处理程序和资源并最终崩溃。
我与 MS Support 谈了很多，他们帮助我缩小了问题的范围。这是他们的最后一封电子邮件：
“我们看到大量的大对象（字符串和数组超过 85000 字节）会导致 GC 堆碎片，从而导致更高的内存 在您的应用程序中使用。我们正在研究如何管理 析构函数，我可以为您提供以下文档：
- 为什么 Finalize/Destructor 示例在 .NET Core 中不起作用？ Why does the Finalize/Destructor example not work in .NET Core? （不是微软官方文档，但可以作为参考）
ASP.NET 案例研究：性能差、内存使用率高和高
GC 中的 CPU – ViewState 死亡：
https://blogs.msdn.microsoft.com/tess/2006/11/24/asp-net-case-study-bad-perf-high-memory-usage-and-high-cpu-in-gc-death-by-viewstate/我将继续寻找更多与 .NET Core 中的析构函数。”
在这之后，他们基本上说 Azure 不是罪魁祸首，我需要开一张“代码”支持票，费用约为 500 美元......
所以我来这里。 :)
虽然我已经成为 .Net 开发人员超过 15 年，但这是我第一次使用 .Net Core。我找到了这篇很棒的文章，并将其用作我的 API (https://chsakell.com/2016/06/23/rest-apis-using-asp-net-core-and-entity-framework-core/) 的主干。
当我将它与其他 .Net Core 示例进行比较时，它似乎与这些示例一致，因此我有理由相信我正在遵循“最佳实践”，但我可能是错的。
我担心.Net Core 存在根本问题（MS 提到的那些文章有点暗示），但我不确定如何找到答案。我不想因此重写我的代码，但除了偶尔重启服务器之外，我不确定我的选择是什么。
想法？
【问题讨论】：
-
似乎根本问题并不是真正的终结器，而是您的程序过度依赖大对象堆（这会导致内存碎片和昂贵的压缩过程）。所以你需要回答的第一个问题是这些分配是从哪里来的。
-
我将从 Kudu 创建/下载转储开始：blogs.msdn.microsoft.com/jpsanders/2017/02/02/…，然后使用 Visual Studio 和“调试托管内存”打开它
-
很难说，我们不知道你的代码。您是否为需要托管内存的服务正确实施 IDisposable 模式？
标签： azure asp.net-core destructor