Thoughts from the EPS Windows Server Performance Team
Today I would like to do a quick walkthrough of the VMMap tool from Windows Sysinternals.
This tool gives us a neat summary of a process’ virtual and physical memory usage. It shows a graphical summary as well as a detailed report of a given process’ memory usage pattern.
VMMap breaks down the memory usage to distinguish space used by file images loaded into the process address space, shared memory, memory used by mapped files, heap, stack, free space and more.
This is useful for one to easily understand where the process’ allocated virtual memory is being utilized.
The main window of VMMap looks like this:
As soon as you open VMMap, you are prompted to choose the process you want to analyze.
Note: You must run this in elevated mode in Windows Vista and higher.
If you want to view a previously saved report just click Cancel and open the saved report from the main window.
It also allows you to compare the two most recent snapshots and view the differences using the Show Changes option.
VMMap also has the following command line switches:
From a performance engineer’s perspective, most of the virtual memory usage questions are related to memory leak issues and are often resolved by the use of the Performance Monitor tool.
However, VMMap is useful in understanding where specifically allocated memory is utilized.
Another good use for this tool is determining the cause of virtual memory fragmentation. Memory fragmentation can cause cases where a memory allocation fails even though you have ample free space available in process’ address space.
In such cases you can look under the “Largest” column under “Free” memory type to find out the largest free block available. If your allocation is larger than the largest free block, your allocation will fail and the program may throw an “out of memory” error.
An example of this is Exchange virtual memory fragmentation, where you sometimes experience memory allocation failures even though you don’t appear to actually be out of memory.
While this tool may be more useful for developers to understand their programs memory usage patterns and tweak them better, we can have our share of VMMap too.
VMMap Download: http://technet.microsoft.com/hi-in/sysinternals/dd535533(en-us).aspx
VMMap is a very nice tool, but for some reason, there is often a mismatch in Private Bytes when comparing to pslist or Process Explorer. The deviation seems to originate from "Image", where the sum of Private Bytes usually does not match the listed sum in the upper pane. The deviation is small unless the module is loaded from a file share, where the full module size seems to be added to the Private Bytes sum. A very small program loading imageres.dll (~20 MBytes on Windows 7) can demo this behavior (both for x86 and x64):
hMod = LoadLibrary("imageres.dll");
//hMod = LoadLibrary("u:\\imageres.dll");
When loading from local disk, total Private Bytes for "Image" remains small, but if you copy imageres.dll to a file share (U:\ in the example above) and load it from there, the full module size seems to be added to the total, but does not appear in the details pane (the module is not relocated in any case). This is just a small demo with simple standard ingredients. If you have a larger application with several modules on a file share, the deviation can be huge. This was tested with VMMap 3.11 on 64 bit Windows 7.