.NET Garbage Collection. Memory Leak. Process using GBs of Private Bytes yet GC .NET Memory counters show only a few MBs

1
votes

I am initially distrusting the results coming back from a perfmon collection against a process that appears to have a memory leak.

The Private Bytes value for the process is over a gig.

So I suspected Garbage collections were not able to clear down memory because something is holding a reference open like a collection etc.

However the .NET memory counters show unexpected values for Gen 0,1,2 heap size.

The values perfmon is bringing back for # Bytes in all heaps for example is only a few million bytes (i.e. a few MBs). Large Object Size is very small too.

I admit I am slightly baffled. I assume this means the memory allocation is outside of managed memory, or is it a bug?

#

Edit

  1. An important point I left out is that GC was not invoked for many weeks

  2. I have a VMMap output I captured a week or so ago, I am wary of running VMMap in prod again, so I cannot capture again (unless anyone is aware how safe VMMap is?)

My VMMap showed close to 900,000 KB size for the managed heap with over 500,000 KB Private Bytes which stuck me as odd when I saw the perfmon values.

1
.netmemory-managementmemory-leaksgarbage-collectionperfmon
I would start with looking at your program with VMmap to understand its memory usage. Then please provide us info about the results. - Konrad Kokosa
I have a VMMap capture from a week ago or so. I will edit the question with this info - ASPNETMVC-Newbie
This may be indication of big memory fragmentation.. But your note about GC not called for weeks is interesting, how you got that? Gen collection counters? Nevertheless, this is a perfect scenario for analysing full memory dump. Do you have one? - Konrad Kokosa
Yes the perfmon counters. No unfortunately as it is prod - ASPNETMVC-Newbie
Without dump it will be really hard to understand what is going on. If your application is load balanced, try to make it on line just after disabling it. Making dump of such size will stop app pool (from my experience) up to 30 sec. The other way is to try to mimic such behavior on test environment, with help of load testing. - Konrad Kokosa

1 Answers

2
votes

The managed heap will always be a subset of private bytes. Private bytes is the amount of memory the process has asked for. This includes native allocations done by the runtime itself or any other module loaded by the process.

Furthermore, the CLR allocates the storage for the managed heap in chunks called segments. The managed heap is basically a collection of segments. The CLR allocates and frees these segments as necessary. At any given point in time there will typically be "free" space on the managed heap. I.e. the segments contribute to the private bytes number, but the memory is considered free by the CLR.

You first action should be to figure out what kind of memory is taking up the space. If it is managed memory, you can inspect the managed heap using a memory profiler or a debugger such as WinDbg/SOS.