.NET 内存泄漏 - 增加峰值，然后回到基线

Question

我对 Azure-app-service-webjob 生产中的内存泄漏问题感到头疼。

这是一个后台工作进程，按计划从队列中读取工作。大约每 10 分钟，内存使用量就会达到峰值，然后（大约 10 分钟后）恢复到正常基线。每个尖峰每次都略高。直到最终，峰值达到足够高（例如 > 80%），因此需要越来越长的时间才能返回基线，最后锁定。

我已经非常详细地登录了。没有大量或大量的数据库查询，并且没有任何处理操作花费超过几秒钟的时间。很难得到非常清晰的跟踪，因为在 10 分钟的周期内可能会发生 15-30 次不同的操作。

无论如何。不久前，当它处于“最大化”阶段时，我得到了一个完整的内存转储，将它插入 WinDbg。尽管数据库中只有几千个，但内存中有数百万个特定类型的实体框架 (6) 个实体。

我无法在本地复制。所以我在这个实体类型的构造函数中添加了一些代码——它保留了从构造函数中看到某个Environment.StackTrace 的次数的Dictionary<string,long>。我正在等待“最大化”发生，但远程连接，目前看起来很标准/正常。

鉴于这些对象/可能/随着时间的推移而增加，但这并不能解释增加的峰值并返回基线。是吗？

我还刚刚在“基线”期间捕获了完整的内存转储，然后是“小峰值”（根据图像仅运行了几个小时）。我有基本的 WinDbg 技能。

无论如何，我的问题/困惑的原因：

1. 如何确定两个完整内存转储之间的差异？
2. 以前有人见过这样的事情吗？
3. 什么会导致内存中的峰值每次都增长？
4. 如果是内存泄漏，为什么它会在峰值之间恢复到基线？

我想没有什么魔法发生，但我根本找不到与尖峰相吻合的东西：

• 数据库记录数逐渐增加，但只有几千条，如果进程重新启动，内存问题会重新设置
• 根据日志记录，尽管峰值持续约 10 分钟，但似乎没有任何操作需要超过几秒钟的时间

Answer 1

如何确定两个完整内存转储之间的差异？

在 WinDbg 中很难做到。使用诸如Jetbrains dotMemory、can import raw dumps、took care using the right format 之类的内存分析工具会容易得多。

有没有人见过这样的事情？

是的。

什么会导致内存峰值每次都增长？ 尽管数据库中只有几千个，但内存中有数百万个特定类型的实体框架 (6) 个实体。

如果你有一个像这样的 O(n²) 循环

foreach(...)
    foreach(...)
        CreateAnObject();

那么数据库中的 1000 行可能会创建 1.000.000 个对象。如果您只是在数据库中再添加一行，那么下次您运行相同的查询时就会多出 2001 个对象。

如果是内存泄漏，为什么它会在峰值之间返回基线？

我不会将尖峰行为称为内存泄漏。看起来还不错。但是，您需要考虑到在某个时间点，RAM 不再足够，并且会发生交换到硬盘的情况。然后，您的应用程序会变得慢得多。也许你可以改变算法。

但是，请注意基线不是恒定的：

所以你确实有内存泄漏，但它与尖峰无关。我不会比较尖峰与非尖峰，而是比较两个基线。

数据库记录的数量逐渐增加，但只有几千条，如果进程重新启动，内存问题会重新设置

如果基线泄漏得到修复，这可能会解决。

根据记录，尽管峰值持续约 10 分钟，但似乎没有任何操作需要超过几秒钟的时间

没有操作？你有什么手术？方法调用？您如何确保测量所有方法调用？下次，您可能还想添加 CPU% 图表。