x86 .net 应用程序与 system.OutOfMemoryException答案

【问题标题】：x86 .net application with system.OutOfMemoryExceptionx86 .net 应用程序与 system.OutOfMemoryException
【发布时间】：2010-05-26 06:40:07
【问题描述】：

应用运行1天后出现OutOfMemoryException，应用总共使用1.5G内存，全部被托管堆消耗，第二代使用200mb，LOB使用1.3mb，但奇怪的是，900mb的空间是免费的.从 perf counter 我看到发生了 gen 2 gc 收集，为什么 GC 收集器无法收集 gen2 和 LOB 中的那些 900mb 可用空间？

非常感谢您的帮助。

以下信息来自windbg：

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x183153f0
generation 1 starts at 0x182aa834
generation 2 starts at 0x02131000
ephemeral segment allocation context: none
 segment     begin allocated  size
02130000  02131000  0312f284  0xffe284(16769668)
07750000  07751000  0874fc5c  0xffec5c(16772188)
09e30000  09e31000  0ae2fc2c  0xffec2c(16772140)
0b230000  0b231000  0c22ffec  0xffefec(16773100)
0c230000  0c231000  0d22f6f0  0xffe6f0(16770800)
0d230000  0d231000  0e22ea10  0xffda10(16767504)
0e230000  0e231000  0f22c1c4  0xffb1c4(16757188)
10390000  10391000  1138ddf4  0xffcdf4(16764404)
154e0000  154e1000  164da90c  0xff990c(16750860)
34aa0000  34aa1000  35a9dbfc  0xffcbfc(16763900)
7aca0000  7aca1000  7bc9edfc  0xffddfc(16768508)
49760000  49761000  4a75ef64  0xffdf64(16768868)
7bca0000  7bca1000  7cc99bac  0xff8bac(16747436)
17a70000  17a71000  183313fc  0x8c03fc(9176060)
Large object heap starts at 0x03131000
 segment     begin allocated  size
03130000  03131000  041250c8  0xff40c8(16728264)
08920000  08921000  099102f8  0xfef2f8(16708344)
....
....
4c760000  4c761000  4d71d578  0xfbc578(16500088)
1bb10000  1bb11000  1ca110d0  0xf000d0(15728848)
57760000  57761000  5862d7f8  0xecc7f8(15517688)
Total Size:              Size: 0x5ab13450 (1521562704) bytes.
------------------------------
GC Heap Size:            Size: 0x5ab13450 (1521562704) bytes.
0:000> !dumpheap -stat
total 0 objects
Statistics:
      MT    Count    TotalSize Class Name
73037c78        1           12 System.Configuration.GenericEnumConverter
73036da0        1           12 System.Configuration.InfiniteIntConverter
....
....
69161c3c    35025      6809420 System.Windows.EffectiveValueEntry[]
69164748       54     12471072 MS.Internal.WeakEventTable+EventKey[]
710e2228     9540    190389260 System.Byte[]
710dd2b8  1317031    339257932 System.String
0035a670     6427    902224056      Free
Total 3615631 objects

【问题讨论】：

我今天遇到了这个错误。它来自一个无限循环-__-
这是什么应用程序？您使用的是哪种通信层？ WCF？

标签： .net out-of-memory

【解决方案1】：

如果您打算使用 WinDBG/SOS，那么请学习使用它；) Tess Ferrandez 关于此主题的许多帖子都是宝贵的资源。

使用 !dumpheap -stat 收集有关消耗堆的对象类型（和数量）的统计信息。

使用 !dumpheap -min 查找至少字节大的对象。

使用 !dumpheap 来确定哪些对象当前驻留在堆的某些部分中。

使用 !gcroot 帮助找到任何让您认为已死的对象保持活力的根。

如果没有关于您的应用和场景的一些详细信息，就很难进一步诊断。一些提示：

看看你是否有任何静态容器或包含很多东西的静态对象。请记住 - 静态对象在应用程序的生命周期中存在。因此，静态容器在应用程序的整个生命周期内都存在，如果它们引用了应该被删除的对象，那么这些对象将继续存在。

另外，请注意，您的应用可能会消耗大量 RAM，因为可能有大量可用 RAM，因此不值得为收集和压缩 LOH 付出代价。

这也可能被证明是非常有价值的： http://msdn.microsoft.com/en-us/magazine/cc534993.aspx

【讨论】：

【解决方案2】：

我不知道那里的 gen2 发生了什么，但我相信大对象堆永远不会被压缩 - 所以它可能是你有效地获得了 900MB 的“间隙”。只是一个猜测，真的......

【讨论】：

是的，我同意你的观点，这是由 LOH 引起的，因为它没有被压缩，有什么办法可以解决？
@Allen：有什么办法可以每 12 小时重新启动一次流程？它不干净，但它的工作量可能比其他任何东西都要少。另一方面，调查为什么你有这么多非常大的物体并试图减少它并不是一个坏主意。

【解决方案3】：

可能值得获得内存分析器。 SciTech 有一个不错的，在他们的网站上有关于如何发现潜在问题的教程。诸如不处理或通过委托留下引用之类的事情可能会使您的内存使用量堆积起来。

【讨论】：

【解决方案4】：

我同意这是 LOH 中的差距。

当我遇到这个问题时，我发现通常会反复创建一两个集合。

我使用的一种解决方案是创建一次集合并将其初始化为可容纳其最终大小的大小。这最初会增加初始内存使用量，但会减少那些 outOfMemory 异常。

【讨论】：