Russinovich

Mark Gives the Real Skinny on Vista Paging File Size

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.

Mighty Mark’s Vista Troubleshooting Tour

For today’s blog, I take great delight in referencing a true Windows luminary’s similar efforts at Microsoft. I’m talking about Mark Russinovich, who continues his efforts with Sysinternals tools and utilities, and anything else that catches his considerable fancy, under the Microsoft umbrella. For those not familiar with Mark’s fabulous skills and abilities, let me observe that he’s the author of the best book on Windows Internals ever written (due in a fifth edition in January 2008, with an exclusive focus on Vista and Windows Server 2008), and a former principal in Sysinternals/Winternals, a company devoted to crafting really great Windows tools and utilities. In a rare and perhaps unequaled display of corporate good sense, Microsoft bought Sysinternals/Winternals in 2005, and continues to make the free Sysinternals software available on their Web pages.

In Mark’s latest blog entitled “The Case of the Sloooooow System,” he delivers a tour-de-force demo of the great Sysinternals tool known as Process Explorer. This nifty tool not only shows you what processes are active on your Windows PC, a la Task Manager’s Processes tab, it also shows you which execution threads belong to those processes, and even lets you suspend them temporarily, thanks to a handy right-click menu facility.

In this troubleshooting exercise, Russinovich makes use of Process Explorer to identify a problem that drags his wife’s Vista desktop into the weeds, performance-wise. He immediately sees that two processes are consuming 100% of the CPU resources between them. Because she’s got a dual-core CPU, each one grabs one of those cores for its exclusive use, thereby freezing out all the other processes (and threads) that want to run on the system. A little quick sleuthing shows that some browser helper object (BHO) is sucking up all the cycles on one core within Iexplore.exe (the process name for Internet Explorer), and that a COM services DLL named Dllhost.exe is doing likewise for the other core.

In the course of identifying his troubles and trying to determine what’s at fault, Russinovich not only shows how to make inspired use of Process Explorer, he also provides some really great information about — you guessed it — Windows internals. He takes us on a journey from Internet Explorer, to one of its specific tabs, and then into the Thread Stack to show us that something about Adobe Flash is hogging that CPU core. For this, there proves to be no obvious fix: no patches, updates, or replacements for the version that’s already running on the machine. The other cycle sucker gets traced back to Roxio Creator, and for this one he does find an update (not yet advertised on Windows Update or via the Creator auto-update functions) that appears to fix the problem. He downloads and installs the update, and does away with one out of two of the problems.

His final assessment of the situation is worth the price of admission all by itself: “My wife’s system was now usable again, and though I wasn’t able to close the Flash-related part of the case, at least I knew the cause and could keep an eye out for updates. More importantly, by solving the Dllhost part of the case, even if Flash went crazy again, her system would still be usable and she wouldn’t be filing a critical support incident for it with me - thanks to Process Explorer and Process Monitor.”

Like any great performance it looks obvious, elegant, and effortless. Only those of us who’ve spent hours trying to troubleshoot runtime gotchas know how much and what kind of experience is necessary to develop such mastery. If you aren’t already familiar with the great Sysinternals toolset, type www.microsoft.com into your Web browser and do some spelunking. You’ll be sure to find some cool stuff, and possibly some great tools you won’t be able to live without a moment longer. You’ll probably want to grab Process Explorer, but be sure to check out the PSTools grab-bag as well.