Hello everyone, I’d like to introduce myself. My name is Ray Ackley and I’m a Support Escalation Engineer in the Performance specialty. I’d like to talk a bit about a new tool that allows us to examine a vital performance resource: physical memory.
This tool is called RamMap and it is available from SysInternals at http://technet.microsoft.com/en-us/sysinternals/ff700229.aspx. It allows us to examine detailed memory usage information in a way that is easy accessible.
Each tab has its own wealth of data, but I’ll be focusing on Use Counts and File Summary tab as they offer the information I think most people will be interested in.
Memory management is a complex beast, so let’s run through a quick refresher of these categories.
Across the top we have:
Active: Pages of physical ram in active use by the specified category (usually a process working set or the system working set).
Standby: Pages of physical ram not actively being used. These are still left in physical ram but will be repurposed first by the memory manager (either returned to the active list or zeroed out and reused) if something needs physical ram for active pages. Standby pages are essentially cache – it’s better to have infrequently used data kept in RAM “just in case” than pushing it out to disk when the memory isn’t needed for anything else.
Modified: Similar to Standby, but these are pages of physical RAM that have been changed and must be flushed to disk before reusing them.
Modified no write: Similar to modified pages but have been marked not to write out to disk.
Transition: Pages that are in transition between any of the other categories.
Zeroed: Pages that have been zeroed out and are ready to be used – they can be quickly allocated for new physical memory allocations. You will usually only see a significant amount of Zeroed pages after a system is booted. After the system has “settled in” you will likely see these pages being put to good use somewhere on the Standby list as cache.
Free: Free pages are free to be used but have some type of “dirty” data in them so they must be zeroed for security reasons before given to a user process. These are usually pages that have been freed by an exiting process. Contrary to the general notation of free memory being good, when you are looking at the Free list here, keep in mind that these pages will be put on the Zeroed list so they are one step closer to being used. This zeroing is periodically done at a low priority by the memory manager’s zero thread, or it can be done on demand when larger numbers of pages are needed and the zero list becomes exhausted.
Bad: These are physical pages that have been marked as bad.
Down the left side we have:
Process Private: Memory allocated for use only by a single process.
Mapped File: Also known as section objects, mapped “views” of files are when the contents of that file are mapped to virtual addresses in memory. This can be a process mapping views of files into its memory (for reading or writing) or for the system file cache. For more details on mapped files, see the references at the end of this post.
Shared Memory: Pages that have been marked as shared can be used by multiple processes.
Page Table: Page tables contain PTEs (Page Table Entries), which describe virtual address usage.
Paged Pool: Kernel pooled memory that can be paged to disk.
Nonpaged Pool: Kernel pooled memory that cannot be paged to disk.
System PTEs: Page Table entries allow the mapping of virtual memory addresses to physical memory addresses. System Page Table Entries are a pool of PTEs used to dynamically map system pages such as I/O space, kernel stacks and the mapping of memory descriptor lists. System PTEs can theoretically describe up to 2GB on x86 system and 128GB on x64 systems. Note that each process also has its own set of PTEs for its own individual virtual address range (0-2GB on x86 systems, 0-8TB on x64 systems). This topic is explained in detail in Chapter 9 of Windows Internals 5th Edition.
Session Private: Memory that is private to a particular logged in session. This will be higher on RDS Session Host servers.
Metafile: Metafile is part of the system cache and consists of NTFS metadata. NTFS metadata includes the MFT as well as the other various NTFS metadata files (see How NTFS Works for more details, and of course Windows Internals is a great reference). In the MFT each file attribute record takes 1k and each file has at least one attribute record. Add to this the other NTFS metadata files and you can see why the Metafile category can grow quite large on servers with lots of files.
AWE: Address Windowing Extensions allows an application to map different views of physical memory into its address space. You will typically see this used by SQL or other database applications.
Driver Locked: These are pages that have been locked in physical RAM by a driver. This can be done for small/temporary purposes like I/O or for larger/longer allocations like RAM drives or other large locked memory reservations. For more details see http://www.microsoft.com/whdc/driver/tips/mmprobe.mspx.
Kernel Stack: The amount of space used by kernel thread stacks. The more threads on the system, the larger this value will be.
The next page of interest is the File Summary tab. The File Summary tab will show you very detailed information about which files are loaded in RAM on your system, including a breakdown of how that memory is being used (Active, Standby, Modified and Modified No-Write). This tab makes it very easy to track down which files are using your RAM.
For example, on this system we have about 7.8GB of RAM being used by Mapped File:
Although 7.2 GB of this is Standby and therefore just cached, it still represents a large amount of RAM being used. So what are we using/caching?
Mystery solved. The outlook offline storage file is taking up the most RAM, followed by my local search index and several thousand smaller files. However, it is important to remember that in this case the memory is almost all on the Standby list, so the OS is simply using the “extra” RAM to cache data for faster access.
For more details please reference the following:
Windows Internals, Fifth Edition
The Memory Shell Game
How NTFS Works
Managing Memory-Mapped Files