Web Debug

Fix broken web applications, from servers to clients.

Troubleshooting .NET Memory Issue

MSDN Magazine - Investigating Memory Issues

Main interface_2Uncovering and correcting memory issues in managed applications can be difficult. Memory issues manifest themselves in different ways. For example, you may observe your application's memory usage growing unboundedly, eventually resulting in an Out Of Memory (OOM) exception. (Your application may even throw out-of-memory exceptions when there is plenty of physical memory available.) But any one of the following may indicate a possible memory issue:

<!--more-->
  • An OutOfMemoryException is thrown.
  • The process is using too much memory for no obvious reason that you can determine.
  • It appears that garbage collection is not cleaning up objects fast enough.
  • The managed heap is overly fragmented.
  • The application is excessively using the CPU.


This column discusses the investigation process and shows you how to collect the data you need to determine what types of memory issues you are dealing with in your applications. This column does not cover how to actually fix problems you find, but it does give some good insights as to where to start.

Garbage Collection and Performance


This topic describes issues related to garbage collection and memory usage. It addresses issues that pertain to the managed heap and explains how to minimize the effect of garbage collection on your applications. Each issue has links to procedures that you can use to investigate problems.

This topic contains the following sections:

CLR GC Toturials

Defrag Tools: #33 - CLR GC - Part 1


Timeline:
[00:00] - What is a Garbage Collector (GC)?
[02:40] - How has the GC changed?
[06:02] - Memory issues
[08:57] - Stress Log (!sos.dumplog)
[10:08] - Troubleshooting and Performance
[12:20] - Demo App
[14:20] - !sos.eeheap -gc
[18:08] - !sos.dumpheap -stat
[20:38] - !sos.dumpheap -mt (Method Table)
[21:58] - !sos.dumpobj / !sos.do (Dump Object)
[24:15] - Performance Monitoring (SOS, PerfView, Performance Monitor)
[28:06] - Measure immediately after an action, not at a cadence
[29:45] - x clr!WKS::GCHeap::GcCondemnedGeneration (Current GC being collected)
[31:15] - bp clr!WKS::GCHeap::RestartEE (Break after a GC)
[35:30] - More next week...

Defrag Tools: #34 - CLR GC - Part 2


Timeline:
[03:30] - How to approach Performance Analysis
[09:00] - Cadence of Gen 0, 1 and 2 garbage collection
[12:20] - !sos.FindRoots
[14:00] - Stop at Gen 1 GC - !sos.FindRoots -gen 1
[16:09] - End of GC: clr!WKS::GCHeap::RestartEE
[17:10] - Stacks of allocations [CLRProfiler] [PerfView]
[18:39] - Object's Generation - !sos.gcwhere
[19:28] - Generation Segments - !sos.eeheap -gc
[24:52] - VM Hoarding
[28:24] - Heap Summary - !sos.heapstat

Defrag Tools: #35 - CLR GC - Part 3


Timeline:
[00:45] - Internal and Externals Roots
[05:55] - Start of GC: clr!WKS::GCHeap::GarbageCollectGeneration
[07:00] - !sos.dumpheap   (Range)
[07:30] - !sos.gcroot   (or !sos.gcwhere )
[09:45] - New Root Types? Dependent Handles (ConditionalWeakTable)
[12:32] - Handle Types
[13:30] - Pinned Handles - Effect on Fragmentation
[15:40] - Large Object Heap's Fragmentation & Coalescence
[17:55] - Pinned Objects
[19:33] - !sos.gchandles
[20:06] - !sos.gchandles -type Pinned
[20:45] - !sos.gchandles -type AsyncPinned

Defrag Tools: #36 - CLR GC - Part 4


Timeline:
[00:38] - PerfView overview
[02:52] - (Basic) Collection
[04:39] - GCStats
[10:10] - GC Rollup By Generation
[11:22] - GC Events By Time (>200ms)
[11:31] - LOH Allocation (>200ms)
[12:34] - Gen2
[12:48] - GC Events By Time
[28:40] - Best Approach to Performance Analysis
[31:03] - GC Collect Only
[32:10] - Channel 9 - PerfView Tutorial

Fork me on GitHub