MSDN Magazine - June 2008 - (Page 19)

Figure 4 Adding Counters in Performance Monitor lems in a managed process that may be related to managed heap (see msdn2.microsoft.com/magazine/cc163528). .NET CLR Memory Performance counters are usually a good first step in investigating performance issues. The counters that are relevant to the LOH are the number of generation 2 collections and the large object heap size. The number of generation 2 collections displays the number of times generation 2 garbage collections have occurred since the process started. The counter is incremented at the end of a generation 2 garbage collection (also called a full garbage collection). This counter displays the last observed value. Large object heap size is the current size in bytes, including the free space, of the Large Object Heap. This counter is updated at the end of a garbage collection, not at each allocation. A common way to look at performance counters is via Performance Monitor (PerfMon.exe). Use “Add Counters” to add the interesting counter for processes that you care about, as you can see in Figure 4. You can save the performance counter data to a log file in PerfMon. Performance counters can also be queried programmatically. Many people collect them this way as part of their routine testing process. When you spot counters with values that are out of the ordinary, you can then use other means to get more details to help with the investigation. (16,754,224 + 16,699,288 + 16,284,504 =) 49,738,016 bytes. And between address 023e1000 and 033db630, there are 8,008,736 bytes occupied by System.Object[] objects; 6,663,696 occupied by System.Byte[] objects; and 2,081,792 occupied by free space. Sometimes you’ll see that the total size of the LOH is less than 85,000 bytes. Why is this? It’s because the runtime itself actually uses LOH to allocate some objects that are smaller than a large object. Since the LOH is not compacted, sometimes people suspect that the LOH is a source of fragmentation. You really need to first clarify what fragmentation means. There’s fragmentation of the managed heap, which is indicated by the amount of free space between managed objects (in other words, what you see when you do !dumpheap –type Free in SoS); there’s also fragmentation of the virtual memory (VM) address space, which is the memory marked as MEM_FREE and which you can see by using various debugger commands in windbg (see go.microsoft.com/fwlink/?LinkId=116470). Figure 6 shows the fragmentation in the virtual memory space (note the red text in the figure). As mentioned earlier, fragmentation on the managed heap is used for allocation requests. It’s more common to see virtual memory fragmentation caused by temporary large objects that require frequent garbage collection to acquire new managed heap segments from the OS and release empty ones back to the OS. To verify whether the LOH is causing VM fragmentation, you can set a breakpoint on VirtualAlloc and VirtualFree and see who calls them. For example, if I want to see who tried to allocate VM Figure 5 LOH Output 0:003> .loadby sos mscorwks 0:003> !eeheap -gc Number of GC Heaps: 1 generation 0 starts at 0x013e35ec generation 1 starts at 0x013e1b6c generation 2 starts at 0x013e1000 ephemeral segment allocation context: none segment begin allocated size 0018f2d0 790d5588 790f4b38 0x0001f5b0(128432) 013e0000 013e1000 013e35f8 0x000025f8(9720) Large object heap starts at 0x023e1000 segment begin allocated size 023e0000 023e1000 033db630 0x00ffa630(16754224) 033e0000 033e1000 043cdf98 0x00fecf98(16699288) 043e0000 043e1000 05368b58 0x00f87b58(16284504) Total Size 0x2f90cc8(49876168) GC Heap Size 0x2f90cc8(49876168) 0:003> !dumpheap -stat 023e1000 033db630 total 133 objects Statistics: MT Count TotalSize Class Name 001521d0 66 2081792 Free 7912273c 63 6663696 System.Byte[] 7912254c 4 8008736 System.Object[] Total 133 objects Using a Debugger Before I begin, you should note that the debugging commands I’ll mention in this section are applicable to the Windows® Debuggers. If you need to look at which objects are actually on the LOH, you can use the SoS debugger extension provided by the CLR, which is explained in the November 2006 installment I mentioned previously. An example output of analyzing the LOH is shown in Figure 5. The red sections of Figure 5 say that the LOH heap size is msdnmagazine.com June 2008 19 http://msdn2.microsoft.com/magazine/cc163528 http://go.microsoft.com/fwlink/?LinkId=116470 http://msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.