Find memory leaks with WinDbg when many objects are present in Gen2

I have a memory problem in my .NET application, where my application starts consuming about 1 GB in the Gen2 heap after everything is initialized and loaded. It slowly over time (4-5 hours) ends up consuming 4 GB in the Gen2 heap. I used WinDbg to analyze what I see that some of my object types (and the associated memory usage) are increasing.

All objects that grow in instances (and memory usage) refer to the same type of parent object. This type of parent has about 3900 instances - it never changes. One way or another, I am adding child objects to some of these parent instances, but I have no good way to find out which of the 3900 instances is being added.

! DumpHeap -mt will show me all my parent types, but the sizes are all the same because they do not account for children.

! ObjSize will count the size of the children, but will only take one object at a time for the argument (or all objects of all types, not just my parent type - this is too many objects)

Considering and tracking child objects is not useful to parents either because there are several million of these types, and I see no way to do some sort of aggregate trace.

Tools like CLRProfiler and ANTS slow down my application too much (ANTS less) to make the problem any reasonable time.

I tried to run my application with a small subset of the data that it usually runs to simplify debugging, but I am not getting memory problems here. I think that in my complete dataset there are some edge cases that cause strange things, but I don't know what these extreme cases are to highlight them in a subset of my entire dataset.

Read about it extensively and cannot see what someone is offering what to do when there are LOTS objects in Gen2 that should be there, and a small number of objects of the same type that continue to grow.

Any advice would be most appreciated.

+7
source share
3 answers

An interesting puzzle. As you know, objects get promoted to gen2 when they survived collections because they have been referenced for a long time. You do not say what kind of application it is - asp.net, WPF, winforms, etc., Therefore, we will have to make some guesses.

One strategy you can try is registration. You say that there are 3900 instances of the โ€œparent objectโ€ to which something is added: can you apply the method to the parent object that accepts new objects? Perhaps by registering these add-ons, you can get an idea of โ€‹โ€‹where they came from.

+1
source

I assume that you are using SOS for this. A better option would be to use PSSCOR2 or PSSCOR4 (depending on which version of the runtime you are on). The PSSCOR !dumpheap has an extra delta column that can help you determine which instances grow over time.

+1
source

You can use !objsize for all objects of your parent type

 .foreach (address {!dumpheap -short -type MyParentType}) {!objsize ${address}} 

or by the method table if your class name is not unique enough

  !name2ee MyModule MyParentType ; *** to get the method table .foreach (address {!dumpheap -short -mt <methodtable>}) {!objsize ${address}} 
0
source

All Articles