5

我的 IIS 应用程序（.NET 4.0、IIS7）在内存中不断增长，最终崩溃，就好像我有内存泄漏一样。

所以我在它大约 1.7GB 的时候拿了一个 DMP 并在 WinDbg 中打开它。

dumpheap -stat 命令显示虽然我在堆中有相当数量的对象，但大多数（以及在查看顺序 DMP 时正在增长的位）被标记为“空闲”（>800MB）：

000007feef55b768 46091 2212368 System.Data.DataRowView
000007fe9739dda8 10355 2236680 Newtonsoft.Json.Serialization.JsonProperty
000007fef4260610 33062 2644960 System.Signature
000007fef4242250 41809 4682608 System.Reflection.RuntimeMethodInfo
000007fef424f058 69232 8847997 System.Byte[]
000007fef4241b28 11 9437680 System.Double[]
000007fef4237ca0 15 9505176 System.DateTime[]
000007fef424c168 32559 11009308 System.Char[]
000007fef424dc30 17271 11795376 System.Int32[]
000007feef555c48 908 17936676[[] System.Data.RB2`1+IncorNode]
000007feef554f58 853 22056952 System.Data.RBTree`1+Node[[System.Data.DataRow, System.Data]][]
000007feef5514b0 541444 51978624 System.Data.DataRow
000007fef424aee0 1550958 132599872 System.String
000007fef422f1b8 183607 178409288 System.Object[]
0000000000d8b2d0 234017 844500226 免费

所以我然后运行“！dumpheap -type Free”，它给了我很多微小的 Free 对象（准确地说是每个 94 字节！），最后还有几个更大的“Free”对象：

00000003098a59b0 0000000000d8b2d0 134 Free
00000003098c19d0 0000000000d8b2d0 102 Free
00000003098ffa00 0000000000d8b2d0 54 Free
0000000309a41d98 0000000000d8b2d0 5961750 Free 000000041f8a1000
0000000000d8b2d0 24 Free 000000042001b4d0 0000000000d8b2d0 16933078 Free
00000004211bf7c8
0000000000d8b2d0 7702 Free
00000004212c1600 0000000000d8b2d0 35173374 Free
00000004236b3be0 0000000000d8b2d0 66886 Free 0000000423cc41e8 0000000000d8b2d0 10778318
Free 0000000424768928 0000000000d8b2d0 2254734 Free 00000004249ec128 0000000000d8b2d0 21166350
Free
000000042600f1e0
0000000000d8b2d0 51366 免费
000000042621bac8 0000000000d8b2d0 114007238 免费

Statistics:
              MT    Count    TotalSize Class Name
000007fef31e7460        1           32 System.Net.SafeLocalFree
0000000000d8b2d0   234017    844500226      Free
Total 234018 objects

注意到“d8b2d0”的重复地址，我运行了一个“！gcroot d8b2d0”，得到了以下结果：

0:000> !gcroot d8b2d0
找到 0 个唯一根（运行 '!GCRoot -all' 以查看所有根）。

所以......毕竟......我有大量的空闲对象卡在我的堆上，GC 没有释放。这会持续大约 2-3 小时。没有其他迹象表明实际类型化的对象有任何内存泄漏。它发生在我们生产中的几乎所有虚拟机上。

有谁知道如何处理在堆上留下这么多空闲对象空间的 GC？

它让我在圈子里跑了好几天。所以向可以帮助我解决这个问题的天才致敬！

4

2 回答 2

2

感谢magicandre1981提出的使用 PerfView 的建议，并且在进行了很多非常大的内存转储之后，我将此问题归结为在 Linq 表达式中使用 DataRow.DefaultIfEmpty() 。它是在两个 DataTable 之间执行 LeftJoin 的支持功能的一部分。

使用 DataRow 枚举中的 DefaultIfEmpty() 作为 Linq 表达式的一部分，我可以在几分钟内重新创建飙升至 4GB+ 的内存空间。通过创建大量的 ItemArrayObjects（小对象堆和大对象堆），其中大部分都存在到 Gen2 GC 集合中。这反过来会导致不断攀升的承诺记忆值。GC2 集合无法跟上小堆，而大堆的重用性较差（如果有的话）。

我们已经取消了这个调用，并且同一个游戏的承诺内存永远不会超过 50MB。我们现在需要看看这对我们的 DataTable 连接有什么影响，但是内存堆之谜已经解决了！

感谢各位的帮助。

于 2015-05-18T13:20:11.087 回答
0

如果您确定您的应用程序存在内存泄漏，我建议您使用内存分析器开始本地分析。这可能比分析生产中的内存转储更快地揭示问题的根源。

于 2015-05-14T09:33:08.393 回答