Virtual memory is a mature, well-understood technology that was first developed in the early 1960s. It's a basic part of every computer science course on operating systems, and it's been a familiar part of Windows since Windows NT first shipped. The idea behind virtual memory systems is that applications (and the OS) can use disk space as a substitute for RAM. The virtual memory manager (VMM) swaps chunks, or pages, of memory in and out as applications request the contents of specific memory blocks. This procedure lets servers handle larger workloads without necessarily requiring a huge amount of physical RAM.
Of course, there's no such thing as a free lunch. If the amount of physical RAM in a computer is insufficient for its workload, the VMM must frequently swap pages to and from disk. As a result, performance can suffer because paging is a disk-bound operation.
Most administrators ignore the virtual memory subsystem in Windows, leaving it alone to do its job—an excellent idea, given that the VMM in Windows is largely self-tuning. It turns out, however, that in some cases you might need to adjust the size of the paging file, the disk-based store used to hold memory contents that are swapped out. Knowing when to adjust the paging file, and what size to use for it, will help you squeeze the best possible performance out of your Exchange servers.
You'll find the basic rule for paging file sizing for Exchange servers on Microsoft's "Exchange 2007 System Requirements" Web page. It's fairly simple: Set the paging file size to equal the amount of physical RAM in the server, plus 10MB. At first glance, this rule seems reasonable—until you consider that Exchange Server 2007, which requires a 64-bit Windows OS, can address large amounts of RAM by virtue of x64 Windows' support for much larger address spaces. Do you really need a 32GB paging file for a server with 32GB of physical RAM? After all, you might think that with so much RAM, the system will never need to page.
In a word, the answer is yes. Exchange 2007 dynamically adjusts the amount of RAM it uses for caching ESE database pages. This dynamic adjustment process was introduced in Exchange Server 5.5 and was known as Dynamic Buffer Allocation. Its implementation is nuanced, but it can be described simply: Exchange grabs as much RAM as it can, then gives back RAM when other applications require it.
One key measure that Exchange uses to decide when to reduce its cache size is the amount of paging going on. Say that you have a server with 16GB of RAM and a 1GB paging file. This configuration is way out of balance and will severely thrash the paging file—that is, generate a large volume of disk I/O by reading and writing pages from disk—when the system is under heavy load. Exchange detects the thrashing and backs off the amount of RAM it uses to cache ESE pages, which then increases the amount of disk I/O required for ESE access, a situation that further hurts server performance.
Paging isn't the only factor that affects how Exchange allocates RAM for its ESE cache, but it's the one that you have the most influence over. Microsoft recommends the nearly 1:1 paging file–to-RAM ratio to keep the amount of paging overhead low, which avoids misleading the Exchange cache allocation algorithm into taking too much or too little RAM. Why the recommendation to add 10MB beyond the server's physical RAM to the paging file? It turns out that Windows uses the paging file to cache some types of internal data (Microsoft hasn't said exactly what), and leaving that 10MB buffer lets Exchange and other memory-intensive applications use paging file space up to the amount of the physical RAM.
