How to identify LOH and Heap Fragmentation

[johan]

Hi,
are there any guide that can explain how to use .net memory profiler to identify Large Object Heap and Heap Fragmentation?

Thanks in advance,
Johan

[Andreas Suurkuusk]

We don't have any guide on how to identify large object heap fragmentation. However, you can get a god idea of how the large object heap is used by enabling "Heap utilization tracking" and looking in the Native memory view. The "Large heap" node in the native memory tree contains information about how much memory is used by the large object heap. The "Large heap" subnode shows how much memory is actually used by live instances, the "Overhead/unused" node shows the memory in the LOH that is not currently used. This number will mainly include memory overhead that is caused by fragmentation of the large object heap.

Native memory large object heap

NativeLargeHeap.png (24.01KiB)Viewed 26306 times

If you enable the heap utilization tracker and select the "Heap utilization" field set (in the toolbar), you will also get information about about the actual instances that are allocated in the large object heap (see attached picture). For more information about the heap utilization tracker, see http://memprofiler.com/OnlineDocs/heapu ... racker.htm.

Allocations in large heap

LargeHeapUtil2.png (37.71KiB)Viewed 26306 times

[johan]

Thanks for the pointer, I'll give it a try asap..

Thanks,
Johan

[johan]

Hi,
I've do some profiling again, against the "the code that produce OutOfMemoryException"
with the screenshot "before_fix.jpg"

suspected code that produce OutOfMemoryException

before_fix.jpg (164.34KiB)Viewed 26282 times

then the second one is the profiler after do "maybe fixed the OOM" and the screenshot "after fix.jpg"

Hopefully fixed the OOM

after_fix.jpg (170.29KiB)Viewed 26282 times

1. Can anyone pointed out that the statistics compare between "before fix.jpg" and "after fix.jpg" are showing "improvement"?
2. which one is the indicator of LOH fragmentation? "Overhead/unused" value or "Unreachable" value?

Thanks in advanced,
Johan

[Andreas Suurkuusk]

I'm sorry for the delay. I didn't notice that you posted a second reply.

The screenshots do not indicate large object heap fragmentation, but they indicate somewhat bad heap utilization, especially after the "fix". The "Unreachable" number identifies the number of bytes used by unreachable instances on the GC heap, that have not yet been GCed. They will be collected when the next full GC is performed. Overhead/Unused in the LOH can be used to identify LOH fragmentation. You do have some LOH overhead, but unless it keeps growing I don't think it will become a big problem. After the fix, you seem to have reduced the LOH size, but the unreachable size in the gen #2 heap has grown instead.

What happens if you keep running the program and collect some more snapshots. Does the number of unreachable bytes, or the number of Overhead/Unused bytes, increase over time?