Production Debugging for .NET Framework Applications 2002

Large Object Heap

The .NET memory manager places all allocations of 85,000 bytes or larger into a separate heap called the large object heap.

This heap consists of a series of virtual memory blocks that are independent from the main managed heap.

Using a separate heap for larger objects makes garbage collection of the main managed heap more efficient because collection requires moving memory,

and moving large blocks of memory is expensive. However, the large object heap is never compacted;

this is something you must consider when you make large memory allocations in .NET.

For example, if you allocate 1 MB of memory to a single block, the large object heap expands to 1 MB in size.

When you free this object, the large object heap does not decommit the virtual memory, so the heap stays at 1 MB in size.

If you allocate another 500-KB block later, the new block is allocated within the 1 MB block of memory belonging to the large object heap.

During the process lifetime, the large object heap always grows to hold all the large block allocations currently referenced,

but never shrinks when objects are released, even if a garbage collection occurs. Figure 2.4 on the next page shows an example of a large object heap.

Where Did My Memory Go?

The next step is to determine which process is using too much memory. Tools such as System Monitor (known as Performance Monitor in Windows 2000) or Task Manager can isolate those processes.

Once you know which process is responsible, you can run AutoDump+ (ADPlus) to create a full memory dump of the Aspnet_wp.exe process and then,

using the WinDbg debugger and the SOS.dll debugger extension, examine the differences between managed and native memory.

This is discussed later in this chapter. If the project is being run in a controlled environment (for example, in development, quality assurance (QA), or test), reproduce the problem and run ADPlus in -hang mode to produce a full memory dump of the Aspnet_wp.exe process. To allow more time before the process becomes recycled, you can use the memorylimit attribute on the element in machine.config to increase the limit from the default of 60 percent to a higher percentage. You can also use .NET APIs or System Monitor to gather more information.

For example, with System Monitor, you can look for patterns that indicate either a .NET managed memory leak or a native memory leak.

Native Memory Consumption

If the Private Bytes counter in System Monitor increases while the .NET # of Bytes in all Heaps counter stays flat, this is evidence of native memory consumption. These counters are discussed in more detail in “Memory Consumption Walkthrough” later in this chapter.

Managed Memory Consumption

When using System Monitor, if both the Private Bytes counter and the .NET # of Bytes in all Heaps counter increase at the same rate, this is evidence of managed memory consumption. Look at the size of allocated managed memory and consider what the GC is doing.

When looking at the dump file, use SOS commands to list the managed heap size and compare it to the total size of the dump file.

Consider what details you can learn about the large object heap and the generations. Look to see if large objects (85 KB or more) or smaller objects consume most of the memory. If it’s the former, look at the details of the large object heap. If it’s the latter, consider what generations 0, 1, and 2 contain.

For large objects, determine if they are rooted, and whether or not they should be rooted. If they aren’t rooted, they are candidates for collections.

Determine if they are eventually collected properly. With WinDbg and SOS.dll, it can be difficult to look at all of the small objects’ details if there are many small objects. In such cases, it might be easier to use the Allocation Profiler to look at details for both large and small objects. “Memory Consumption Walkthrough” uses all of these tools to diagnose a memory consumption issue.