CODEWITHSUNDEEP
.netmemory-managementmemory-leaksgarbage-collectionperfmon
ASPNETMVC-Newbie
ASPNETMVC-Newbie

Reputation: 177

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

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.

Upvotes: 1

Views: 1068

Answers (1)

Brian Rasmussen
Brian Rasmussen

Reputation: 116401

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.

Upvotes: 2

Related Questions