Debugging,  Learning,  Performance

Exploring Large Object Heap with WinDBG

This is the second part of, – which is far from complete. In this post, we will explore the Large Object Heap (LOH) of a .NET application with WinDBG

Why LOH? It’s a special heap contains the memory objects which are more than 85000 bytes in size – which, previously, never compacted (that was changed with .NET 4.5 when you have an option to compact LOH, but beware of the consequences).

If you know about the generation garbage collection in CLR, you already know that when an object is no longer used, its memory will be claimed back for later use. GC do more than that, by trying to compact the “free” memory – so it’ll move (via copy and delete) the survived objects next to each other, therefore you’ll be a big, continuous free memory. This helps improving performance in upcoming allocations, but only until a point. If the objects are too big, then the costs of moving the objects around might outweigh the benefits. Microsoft did a bunch of performance test and they decided that 85000 bytes is the break point, where the costs are bigger than the performance gain. Then we have LOH, where the memory is almost never compacted.

Because LOH is expensive, both in creating and reclaiming – it should be used with some cautions. LOH’s objects should be long lived, preferably the entire application lifetime.  So, if you have LOH objects constantly filled up/freed, that would be a bad sign for performance.

The first steps – as usual, is to load the memory dump, and the load the sos and sosex modules and we can start working. To retrieve information about the LOH, sos extension provide an export !eeheap -gc

So we can see this application has two heaps. Each heap has a LOH segment.  We can explore one by one.

To investigate the first one, we can simply use !dumpheap <Starting address of LOH>

So what do we expect to find here? The number of large objects, and the status of them.

You can of course use the -stat argument to have a summarized result:

So here we have 58 of “freed” objects, taking about 350MB of memory. This information is not exactly helpful on it own. However, if you continue to run the application and take another memory dump, and it has even more “freed” objects – then it might be a problem: Your site might be using LOH more than it should.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: