A colleague of mine, John Allen, created an awesome tool way back that displays memory usage in a process very nicely. I use screenshots from it from time to time in presentations or posts but unfortunately that tool is not publicly available.
Since lots of people have asked me about it I figured I would just do a quick and dirty mock-up (based on the same ideas) and post the VS solution here.
This sample tool will give you a visual overview of the virtual memory space (from a memory dump), show you where your allocations exist and what types of allocations you have. For example in the screenshot below you can see that at the beginning of the memory space we have a lot of virtual allocations (dark green – committed, light green - reserved), then we have a lot of free space (white) and towards the end of the memory space we can see our dlls scattered out (dark red).
In the bottom screen we can see our GC (.NET) Heaps. In other words, most of the virtual allocations we see in the top screen are really GC Heaps. One little caveat is that for the GC heaps it doesn’t show what is reserved for the GC heaps, only what is committed, i.e. what we actually use.
I have separated them out so that you can use the tool for non-.net apps as well if you want to.
The purpose of looking at something like this is to get a grasp for how much fragmentation we have, how much reserved vs. committed memory we have etc. and if we do have a lot of fragmentation, where should we start looking in order to reduce it.
The original tool is a bit more complex as it can read in memory dumps etc. and lets you zoom into different areas to get more details but for the most part what you see above is enough.
<disclaimer> The sample tool posted here is almost completely void of error handling, and does a lot of output parsing so just be aware that it is by no means claiming to be robust… I just wanted to get it out there so you have the functionality </disclaimer>
To use the sample tool follow these steps:
1. Open the memory dump in windbg and set the symbols properly
.symfix c:\mycache .reload
.symfix c:\mycache .reload
2. Run !address and copy the output to a text file.
3. Load sos
.loadby sos mscorwks
.loadby sos mscorwks
4. Run !eeheap –gc and copy the output to another text file
5. Open the tool, click on Load !address and load the !address output, click on Load !eeheap –gc and load the !eeheap –gc output
Suggestions for features you might want to implement:
There is a lot of info stored in just these two files, including how much memory the process is using, how much is reserved and committed etc. as well as sizes of GC heaps, number of GC heaps and so on.
I didn’t have time to add all this but it would probably be nice to show it, as well as automatically gathering the info from a dump, or even doing the right-click on a memory area for more info + zoom in.
Feel free to build on it, and if you do and post it somewhere, please add a comment with a link to your version and share the wealth:)
Have fun, Tess
PingBack from http://asp-net-hosting.simplynetdev.com/show-me-the-memory-tool-for-visualizing-virtual-memory-usage-and-gc-heap-usage/
A colleague of mine, John Allen, created an awesome tool way back that displays memory usage in a process
I wrote a similar tool, but rather than using output from windbg, I gather as much information as I can from the process live, based on procID. Obviously, this is a different situation, but I feel like it might be useful for people diagnosing issues with virtual address space.
I originally wrote it cause we were having severe fragmentation issues, and I wanted to visually see how our DLLs and whatnot were laid out in address space.
Holding Left-button pans around, and holding right-button zooms in. Hope its helpful.
Very nice PJ...
For some reason it started going into an infinite loop in the opengl libraries the 2nd time i used it, im guessing it will probably work again if i reboot. But i got a chance to try it once and really liked it
Very cool Tess, Thanks for sharing.
cool. What about putting it up on codeplex so people could contribute changes to it =)
Thank you for submitting this cool story - Trackback from DotNetShoutout
I was thinking CodePlex is a good place for it as well.
My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. US ISV Developer Evangelism Team posted some links to money saving offers for ISVs when purchasing or upgrading Visual Studio or MSDN
Alas, !eeheap gives an error message of "Doesn't work with 2.x" in the latest version of WinDbg (6.11.0001.404)
When will these commands work with .NET 2.0+?
!eeheap works in 2.0, you just need to use the 2.0 version of sos.dll
Just found this little jewel and we have found some use for it. I do have a question though, the Heap Allocs, are these unmanaged allocs?