Posted by: Ed Tittel
Desktops, Enterprise desktop, paging file size, physical memory, Process Explorer, Russinovich, Sysinternals, virtual memory, Windows Vista, Windows Vista troubleshooting
Sometimes, the information I come across on Vista internals is just too good not to pass along. And when it comes to Vista internals nobody knows (or does) them better than Mark Russinovich, formerly a principal at SysInternals, now a Microsoft Fellow. In discussing paging file sizes in the context of Vista, Mark makes the following wonderful observation which accords entirely with my own experience:
There’s no end of ridiculous advice out on the web and in the newsstand magazines that cover Windows, and even Microsoft has published misleading recommendations. Almost all the suggestions are based on multiplying RAM size by some factor, with common values being 1.2, 1.5 and 2.
This comes from his November 17, 2008 blog entitled “Pushing the Limits of Windows: Virtual Memory,” wherein he also digs into process address spaces, explains how virtual memory gets mapped in the 32- and 64-bit worlds, and talks about committed memory that processes essentially get to own as they’re executing and the commit limit that sets the ceiling on such allocations. Along the way, he also uses his snazzy Testlimit (and Testlimit64) tool to demonstrate these principles in action.
All this detailed and exquisite discussion leads back to what’s really involved in sizing a paging file. It is best to understand that the commit limit imposes a ceiling on how much private (process-based) and pagefile (system-based) virtual memory can be allocated at any given moment by actively running processes. Thus the key comes from knowing the total sum of commit charges for all programs you’d like to have running concurrently. The commit limit must exceed that sum, or trouble will ensue.
His sizing approach is pretty simple: fire off all the applications you’d like to use together, then use SysInternals Process Explorer to measure the Peak Commit Charge. In fact, Russinovich recommends examining this value after running your target collection for a while to make sure you reach maximum load. After that, the formula is:
Size of Paging File = Peak Commit Charge – Amount of Physical RAM in system
If that number is negative, that doesn’t mean you want no paging file. It should be set to no smaller than whatever kind of memory dump you’ve got configured for crash reporting (default value is around 135 KB or miniscule, but a complete memory dump has to match the amount of accessible memory–same value that shows up as Total under Physical Memory in Task manager–for that memory dump to occur). By default Vista sizes the paging file to equal total memory plus 300 MB or 1 GB, whichever is larger. On my Vista machine my maximum commit limit runs at around 2.5 GB, but I’ve left the paging file alone at 3881 MB (equal to usable memory of 3,581 MB plus the aforementioned 300 MB) so I can generate a memory dump if and when I must.
On notebook and desktop PCs not quite so lavishly endowed with RAM, you can probably get by with cutting the paging file somewhat by following Mark’s formula. If you need to capture a memory dump at some point, you can always increase the paging file to accommodate that need for so long as you must capture memory dumps, then revert to earlier values after that exercise concludes.