问题
We have a .NET application which our customers consider too large for mass deployment and we would like to understand what contributes to our memory footprint and is it possible to do any better without completely abandoning .NET and wpf.
We are interested in improving both Total Size and the Private Working Set (pws). In this question I just want to look at pws. VMMap typically reports a pws of 105 mb. Of this 11mb is image, 31mb is heap, 52 mb is managed heap, 7 mb is private data and the rest is stack, page table etc.
The largest prize here is the managed heap. We can account for approx 8mb of the manged heap directly within our own code, i.e. objects and windows we create and manage. The rest is presumable .NET objects created by the elements of the framework that we use.
What we would like to do is identify what element of the framework account for what portion of this usage and potentially re architect our system to avoid their use where possible. Can anyone suggest how this investigation can be done?
Further clarification:
I have used a number of tools so far, including the excellent ANTS profilers and WinDbg with SOS, and they do allow me to see the objects in the managed heap, but of real interest here is not 'What?', but 'Why?' Ideally I would like to be able to say, "Well, there a 10mb of objects been created here because we use WCF. If we write our own native transport we could save 8mb of that with x quality risk and y development effort."
Doing a gcroot on 300,000+ objects is not possible.
回答1:
WinDbg might be a useful tool for you. It comes with the Debugging Tools for Windows.
Once your app is running, you can attach WinDbg and explore the managed heap. (Or you can take a memory dump and explore it offline). It will be able to very quickly tell you the object types consuming the largest amounts of memory.
First you will need to load the SOS extension which enables debugging of managed applications:
.loadby sos mscorwks
Then you can use !dumpheap to get heap information, the -stat switch gives overall heap info on which types are allocated:
!dumpheap -stat
The -type parameter gives specific information on allocated instances of the specified type:
!dumpheap -type System.String
There's a bunch of other commands you might find helpful like:
!gcroot- to follow an allocated object back up it's root to find why it is in memory.!dumpobj- to dump out a specific object so you can see it's contents.!EEHeap- to give some general heap stats.
MSDN has a full list of SOS commands and their switches.
WinDbg is a pretty complex tool, but there are lots of tutorials and guides online if you search to help you get started. Alternatively, I can recommend the book Debugging Microsoft .NET 2.0 Applications by John Robbins which goes into some good detail in the .net debugging abilities of WinDbg and SOS.
You can load the SOS extension into visual studio instead by entering this into the immediate window, then you should be able to use the SOS commands directly in the VS immediate window:
.load SOS.dll
You also might find the CLR Profiler and this Usage guide helpful.
回答2:
The new tool is PerfView which can show reference tree and also do diffing
回答3:
CLR profiler also shows memory allocated by type in the heap graphically.
回答4:
I am using .NET Memory Profiler. This is also used by some Microsoft teams internally as told by a PDC podcast.
回答5:
Any decent memory profiler will show you this information. You don't really want to mess with the free CLR Profiler, it isn't worth your time, get a decent 3rd party tool. You'll find them mentioned in this thread.
来源：https://stackoverflow.com/questions/2957105/how-can-you-explore-the-managed-heap-in-a-net-application-to-identify-possible