asp.net - ASP.NET 中 FileMonitorTarget/CacheDependency+DepFileInfo 的内存泄漏

Question

在我们的 ASP.NET 网络应用程序中，我们遇到了相当广泛的内存泄漏，我现在正在调查。使用 WinDbg，我找到了我们应用程序中最大的内存消耗者(在 WinDbg 控制台中运行 !dumpheap -stat 以获取这些):

MethodTable Addr   Count  Overall size Type
...
000007fee8306e10   212928     25551360 System.Web.UI.LiteralControl
000007feebf44748   705231     96776168 System.Object[]
000007fee838fd18  4394539    140625248 System.Web.Caching.CacheDependency+DepFileInfo
000007fee838e678  4394614    210941472 System.Web.FileMonitorTarget
000007feebf567b0    18259    267524784 System.Collections.Hashtable+bucket[]
00000000024897c0     1863    315249528      Free
000007feebf56cd0    14315    735545880 System.Byte[]
000007feebf4ec90  1293939   1532855608 System.String

据我所知，大量的 String 对象是很正常的；仍然有改进的空间。但真正让我心痒痒的是 System.Web.FileMonitorTarget 对象的数量:我们在堆上有超过 400 万个实例(à 48 字节)!使用两个内存转储并比较它们，我发现这些对象没有被 GC 清理。

我想弄清楚的是:这些对象是从哪里来的？我已经尝试使用 ANTS Memory Profiler 来找出问题的根源，但它与我们自己的任何类(class)都相去甚远。我看到与 System.Web.Caching.CacheDependency+DepFileInfo 的连接，因此 System.Web.Cache 但我们不使用文件依赖项来使我们的缓存无效条目。

此外，System.Byte[] 的 14315 个实例在堆上占了超过 700 MB，这让我感到震惊 - 我们唯一使用 Byte[] 的地方> 是我们的图片上传组件，但我们每天只有大约 30 张图片上传。

这些 Byte 数组和 FileMonitorTarget 对象的来源可能是什么？非常欢迎任何提示!

奥利弗

附言有人问了几乎相同的问题 here但那里唯一的“答案”非常笼统。

Answer 1

我会研究几件事。你是对的，字符串经常被大量使用。你还有大约。堆上有 1.4 GB 的字符串。听起来对吗？如果没有，我会调查一下。如果那在预期范围内，请忽略它。

如果您怀疑 FileMonitorTarget 和/或 Byte[] 发生泄漏，请使用 !dumpheap -mt XXX 转储实例，其中 XXX 是列出的类型的 MethodTable。您可能希望使用 PSSCOR2 而不是 SOS，因为它使此任务更容易一些(!dumpheap 的输出显示一个增量列，您可以限制转储的实例数)。

接下来要做的是开始调查是什么让特定实例保持事件状态。 !gcroot 命令会告诉您什么是特定实例的根。随机选择一个实例并检查根。如果一切都符合预期，请继续下一步。如果您的应用程序正在泄漏这些类型的实例，您很可能会得到一个本应被释放的实例。一旦你找到了根源，你需要弄清楚代码的哪一部分坚持这些。一个常见的来源是未订阅的事件，但对象保持事件状态还有其他可能的原因。