C# memory usage

Question

How I can get the actual memory used in my C# application?

• Task Manager shows different metrics.
• Process Explorer shows increased usage of private bytes.
• Performance counter (perfmon.msc) showed different metrics
• when I used .NET memory profiler, it showed most of the memory is garbage collected and only few Live bytes.

I do not know which to believe.

Answer 1

Memory usage is somewhat more complicated than displaying a single number or two. I suggest you take a look at Mark Russinovich's excellent post on the different kinds of counters in Windows.

.NET only complicates matters further. A .NET process is just another Windows process, so obviously it will have all the regular metrics, but in addition to that the CLR acts as a memory manager for the managed application. So depending on the point of view these numbers will vary.

The CLR effectively allocates and frees virtual memory in big chunks on behalf of the .NET application and then hands out bits of memory to the application as needed. So while your application may use very little memory at a given point in time this memory may or may not have been released to the OS.

On top of that the CLR itself uses memory to load IL, compile IL to native code, store all the type information and so forth. All of this adds to the memory footprint of the process.

If you want to know how much memory your managed application uses for data, the Bytes in all heaps counter is useful. Private bytes may be used as a somewhat rough estimate for the application's memory usage on the process level.

You may also want to check out these related questions:

Reducing memory usage of .NET applications?

How to detect where a Memory Leak is?

Answer 2

If you are using VS 2010 you can use Visual Studio 2010 Profiler. This tool can create very informative reports for you.

Answer 3

If you want to know approximately how many bytes are allocated on the GC heap (ignoring memory used by the runtime, the JIT compiler, etc.), you can call GC.GetTotalMemory. We've used this when tracking down memory leaks.