Perfmon counters to check memory leak

Question

I want to check the memory leakage issue in my service. I have tried following set of perfmon counters.

1. .NET CLR Memory\# Bytes in all Heaps
2. .NET CLR Memory\Gen 2 Heap Size
3. .NET CLR Memory\# GC handles
4. .NET CLR Memory\# of Pinned Objects
5. .NET CLR Memory\# total committed Bytes
6. .NET CLR Memory\# total reserved Bytes
7. .NET CLR Memory\Large Object Heap size

I have referred above set from here

Also referred following set:

1. Memory/Available Bytes
2. Memory/Committed Bytes
3. Process/Private Bytes
4. Process/Page File Bytes
5. Process/Handle Count

I have referred above set from here

Is there any parameter/criteria or any other best way to identify perfmon counter for memory leak?
Can any one suggest me set of counters to check memory leak? Or above sets covers memory leak?

Solution 1

To detect a memory leak using Performance Monitor, monitor these counters:

1. The Memory/Available Bytes counter lets you view the total number of bytes of available memory. This value normally fluctuates, but if you have an application with the memory leak, it will decrease over time.
2. TheMemory/Committed Bytes counter will steadily rise if a memory leak is occurring, because as the number of available bytes of memory decreases, the number of committed bytes increases.
3. The Process/Private Bytes counter displays the number of bytes reserved exclusively for a specific process. If a memory leak is occurring, this value will tend to steadily rise.
4. The Process/Page File Bytes counter displays the size of the pagefile. Windows uses virtual memory (the pagefile) to supplement a machine's physical memory. As a machine's physical memory begins to fill up, pages of memory are moved to the pagefile. It is normal for the pagefile to be used even on machines with plenty of memory. But if the size of the pagefile steadily increases, that's a good sign a memory leak is occurring.
5. I also want to mention the Process/Handle Count counter. Applications use handles to identify resources that they must access. If a memory leak is occurring, an application will often create additional handles to identify memory resources. So a rise in the handle count might indicate a memory leak. However, not all memory leaks will result in a rise in the handle count.

Source

In my experience this is accurate.

I'd also refer you to this Microsoft Advanced Debugging blog by Tess, a Microsoft employee. Who suggests the following counters. I have found the above to be more than enough to indicate a memory leak is present but I trust that Tess's instructions could provide a more indepth insight into the issue.

Debugging Demos - Memory Review

• .NET CLR Memory/# Bytes in all Heaps
• .NET CLR Memory/Large Object Heap Size
• .NET CLR Memory/Gen 2 heap size
• .NET CLR Memory/Gen 1 heap size
• .NET CLR Memory/Gen 0 heap size
• Process/Private Bytes
• Process/Virtual Bytes

Solution 2

There are better tools available to make memory leaks testing easier such as RedGate ANTS Memory Profiler and JetBrains dotMemory Profiler.

However if you want to use Performance counters, this article explains how to use Performance Counters to test memory leaks.

Keep in mind that Garbage Collection doesn't release memory immediately after some instance dispose. It has been optimized to trigger and release memory only when there is a memory stress. So, if you want to test for memory leaks you should execute Garbage Collection manually before you take counter readings.

GC.Collect();
GC.WaitForPendingFinalizers();

Comments

[stijn]

Checking some processes Private bytes and Page File Bytes, they are exactly the same (even though there are several GB of free physical memory). Does this really mean the entire process' memory comes from the pagefile instead of physcial memory, or is the meaning of Page File Bytes more nuanced?