Red Gate Memory Tracker
From RedGateWiki
Contents |
Introduction
Every so often I find I'm working on an application and my task is to work out why it's using so much memory. I've had this problem at various different companies. "Product X has a massive memory footprint, and we need to reduce it. Find out why it's taking up 1GB of RAM even before we throw real data at it."
With existing tools this can be extraordinarily difficult. Using the Visual Studio debugger doesn't prove to be much help. All you can see are the loaded modules, and you can calculate their sizes by doing a dir at a command prompt, or through Explorer. Windows Task Manager will tell you how much virtual memory your application is using, but not what it's using it for. Process Explorer, from http://www.sysinternals.com, is also very handy, and can save you a bit of trouble; but it still won't tell you where all your memory's going.
Googling has, on numerous occcasions, generally provided nothing of value. The best I've found are applications which will give you a linear, text list of all the virtual memory memory blocks allocated in the process, and how much space each consumes.
Recently I discovered the process was improved somewhat by using WinDbg. For both managed and unmanaged applications, assorted WinDbg extensions prove extraordinarily handy, provided you know the correct mojo to invoke. Even so, you're left with what is basically a highly manual task.
Enter Red Gate's Memory Tracker (a highly provisional name, by the way), which attempts invoke Red Gate's mantra of ingeniously simple tools, and provide you a one-stop, automated, graphical way of solving this problem.
Using Memory Tracker
Simply fire up the Memory Tracker and choose a running process from the drop down. Memory Tracker will analyse the process' memory usage, and provide you with a graphical memory map of the entire user address space. You can pan around by clicking the left button and dragging; you can zoom in and out with the mouse wheel.
Memory blocks are colour coded to indicate their content type, and patterned to indicate the access controls on that memory. Mouse over the memory block for more information: a tooltip will describe the memory content type, sub type, and any additional information available.
Take for example the memory occupied by a DLL. PE files (that's DLLs and executables) are split into sections, containing code, read-only data, and writeable data. When the DLL is loaded, those sections are preserved in memory. So in the Memory Tracker, you can see not only which DLLs are loaded, and the relevant product, version and company information for that library, but the size of each individual section in the library. You can visually distinguish between code blocks, static data blocks, and writeable data blocks.
The Memory Tracker doesn't just identify DLLs. It can display memory used by both system (Microsoft) and user (non-Microsoft) DLLs; memory on Windows process heaps, both allocated and free; memory on .NET heaps, both the managed heap and the large object heap; memory consumed by the .NET runtime for other purposes (such as JIT code compilation); and general virtual memory, both reserved and committed. Of course, it also shows you free memory.
Although I'm somewhat biased, I find this a vaguely entertaining tool to use. Run it against SQL Server to see the large memory blocks SQL Server reserves for efficiency purposes (and watch that memory get fragmented over time). Run it against Visual Studio after you've had the application open for a few days on multiple projects, and observe that all those projects' libraries are still in memory. Run it against any application which accesses SQL Server (including some of Red Gate's leading tools) and observe the vast number of DLLs which have to be loaded for this purpose.
In any case, version 0.2 is here for you to play with.
System Requirements
Microsoft Windows 2000, XP or Server 2003 (32-bit edition)
Microsoft .NET Runtime 1.1 must be installed (see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=262D25E3-F589-4842-8157-034D1E7CF3A3)
Debugging Tools for Windows* must be installed (see http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
An active internet connection*.
(* Memory Tracker makes use of low level APIs provided by the Microsoft Debugging tools, notably access to the Microsoft symbol server, msdl.microsoft.com. For this reason you need both the Debugging Tools for Windows installed, and an active internet connection permitting access to this location. Rest assured, Memory Tracker does not "phone home" or communicate any personal information whatsoever.)
Download
http://www.red-gate.com/downloads/labs/MemoryTracker_v0_2_RedGateLabsRelease2.zip
Installation Instructions
Download the zip file and extract it to a location on your local machine. Note that you won't be able to run it over a network share, as .NET will complain bitterly.
Memory Tracker may create temporary files in directories alongside its executable (containing symbol information). These do not need to be retained after running the application, although preserving them will speed future uses of the application.
Discussion Forum
Though Memory Tracker is an unsupported, experimental release, do feel free to post comments and questions on our forum:
