x86 .net application with system.OutOfMemoryException

Question

Hi,Guys I got OutOfMemoryException after the app running for 1 day, the app totally use 1.5G memory , all consumed by managed heap, gen 2 used 200mb , and LOB used 1.3mb, however the weired thing is, 900mb of space are Free. from perf counter I saw there had number of gen 2 gc collection happened, why GC collector cannot collect those 900mb free space in gen2 and LOB?

I'm really appreicate for your help.

following info are from 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

Answer 1

I don't know what's going on with gen2 there, but I believe the large object heap is never compacted - so it could be that you've got 900MB of "gaps" effectively. Just a guess though, really...

Answer 2

Might be worthwhile getting a memory profiler. SciTech have a nice one, with tutorials on their website about how to find potential problems. Things such as not disposing, or leaving a reference through a delegate can make your memory usage pile up.

Answer 3

I agree that is the gaps in the LOH.

When I have run into this problem I have found that there is usually one or two collections that are created over and over again.

One solution I use is to create the collection once and initialize it to a size that will accommodate the size it will eventually become. This bumps up initial memory usage initially but reduces those outOfMemory exceptions.

Answer 4

If you're going to use WinDBG/SOS, then learn to use it ;) Tess Ferrandez' many posts on this subject are an invaluable resource.

Use !dumpheap -stat to gather stats on the types (and number of) of objects consuming your heaps.

Use !dumpheap -min to find objects which are at least bytes big.

Use !dumpheap to identify what objects currently reside in portions of your heap.

Use !gcroot to help find any roots that are keeping objects alive that you thought were dead.

Without some details about your app and your scenarios, it's kinda hard to diagnose further. Some tips:

See if you have any static containers or static objects that contain lots of things. Remember - static objects live for the life of the app. Static containers therefore, live for the life of the app and if they're referencing objects which should have been removed, then the objects will continue to live.

Also, note that your app may well consume huge amounts of RAM because there may be plenty of free RAM so it's not worth the cost of collecting and compacting the LOH.

This may also prove to be very valuable: http://msdn.microsoft.com/en-us/magazine/cc534993.aspx