In modern operating systems, including Windows, application programs and many system processes always reference memory using virtual memory addresses which are automatically translated to real (RAM) addresses by the hardware.  Only core parts of the operating system kernel bypass this address translation and use real memory addresses directly. 
 
Virtual Memory is always in use, even when the memory required by all running processes does not exceed the amount of RAM installed on the system.
 
An expanded version of this article is available at:

http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm (http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm)

 
Processes and Address Spaces
 
All processes (for example, application executables) that run under 32-bit versions of Windows get virtual memory addresses (a Virtual Address Space) that range from 0 to 4,294,967,295 (2*32-1 = 4 GB), no matter how much RAM is actually installed on the computer. 
 
In the default Windows configuration, 2 GB of this virtual address space is designated for private use of every process, and the other 2 GB is shared between all processes and the operating system. Typically, applications such as Notepad, Microsoft Office Word, and Adobe Acrobat Reader use only a fraction of the 2 GB of private address space. The operating system assigns RAM page frames only to virtual memory pages that are in use.  
 
Physical Address Extension (PAE) is a feature of the Intel 32-bit architecture that expands the physical memory (RAM) address to 36 bits. (For more information, see Microsoft Knowledge Base article 268363, Intel Physical Addressing Extensions (PAE) in Windows 2000 (http://support.microsoft.com/default.aspx?scid=kb;en-us;268363) ).  PAE does not change the size of the virtual address space, which remains at 4 GB. It changes only the actual RAM that can be addressed by the processor.
 
The translation between the 32-bit virtual memory address that is used by the code running in a process and the 36-bit RAM address is handled automatically and transparently by the computer hardware according to translation tables maintained by the operating system. Any virtual memory page (32-bit address) can be associated with any physical RAM page (36-bit address).
 
Here's a list of how much RAM the various Windows versions and editions support (as of May 2010):

Windows NT 4.0: 4 GB
Windows 2000 Professional: 4 GB
Windows 2000 Standard Server: 4 GB
Windows 2000 Advanced Server: 8 GB
Windows 2000 Datacenter Server: 32 GB
Windows XP Professional: 4 GB
Windows Server 2003 Web Edition: 2 GB
Windows Server 2003 Standard Edition: 4 GB
Windows Server 2003 Enterprise Edition: 32 GB
Windows Server 2003 Datacenter Edition: 128 GB
Windows Vista: 4 GB
Windows Server 2008 Standard: 4 GB
Windows Server 2008 Enterprise: 64 GB
Windows Server 2008 Datacenter: 64 GB
Windows 7: 4 GB
 
Pagefile
 
RAM is a limited resource, whereas virtual memory is, for most practical purposes, unlimited. There can be many processes, each one having its own 2 GB of private virtual address space. When the memory that is in use by all the existing processes exceeds the amount of available RAM, the operating system moves pages (4 KB pieces) of one or more virtual address spaces to the hard disk, thus freeing that RAM frame for other uses. In Windows systems, these “paged out” pages are stored in one or more files that are named pagefile.sys in the root of a partition. There can be one such file in each disk partition. The location and size of the page file is configured in Control Panel. To set these values, click System, click Advanced system settings, and then click Settings under Performance.
 
A frequently asked question is how big should I make the pagefile? There is no single answer to this question because it depends how much RAM is installed and how much virtual memory that workload requires. If there is no other information available, the typical recommendation of 1.5 times the amount of RAM that is in the computer. On server systems, a common objective is to have enough RAM so that there is never a shortage and so that the pagefile is essentially not used. On these systems, having a very large pagefile may serve no useful purpose. On the other hand, disk space is usually plentiful, so having a large pagefile (for example, 1.5 times the installed RAM) does not cause a problem and eliminates the concern about how large to make it.
 
Performance, Architectural Limits, and RAM
 
On any computer system, an increase in the load (number of users, amount of work being done) causes a decrease in performance (how long it takes to do each task). However, this occurs in a non-linear fashion. Any increase in load (demand) beyond a certain point results in a dramatic decrease in performance. This means that some resource is in critically short supply and has become a bottleneck.
 
At some point, the resource in critical short supply cannot be increased. This means that an architectural limit has been reached. Some commonly reported architectural limits in Windows include:

• 2 GB of shared virtual address space for the system (kernel)
• 2. 2 GB of private virtual address space per process (user mode)
• 3. 660 MB System PTE storage (Windows Server 2003 and older)
• 4. 470 MB paged pool storage (Windows Server 2003 and older)
• 5. 256 MB non-paged pool storage (Windows Server 2003 and older)

This list applies to Windows Server 2003 specifically (from Knowledgebase article 294418 (http://support.microsoft.com/default.aspx?scid=kb;en-us;294418) ), but also applies to Windows XP and Windows 2000. Windows Vista, Windows Server 2008 and Windows 7 do not have all of these same architectural limits. The limits on user and kernel memory (the first two list items) are the same, but kernel resources such as PTEs and various memory pools are dynamic. This new functionality enables both paged and non-paged memory and also PTEs and session pool to grow beyond the limits set in this list. This continues up to the point at which the entire kernel is depleted.

"On a Terminal Server, the 2 GB of shared address space will be completely used before 4 GB of RAM is used.”
 
Such statements as this one may be true in some situations, but you have to monitor the system to know whether this or similar beliefs apply to your particular system. In some cases, these statements are conclusions from specific Windows NT 4.0 or Windows 2000 environments that don't necessarily apply to Windows Server 2003. Significant changes were made to Windows Server 2003 to reduce the likelihood that these architectural limits will in fact be reached in practice. For example, some processes that were in the kernel have been moved to non-kernel processes to reduce the amount of memory used in the shared virtual address space.
 
Monitoring RAM and Virtual Memory usage
 
Performance Monitor  is the principle tool for monitoring system performance and identifying what the bottleneck really is. To start Performance Monitor, open Control Panel, click Performance Information and Tools, click Advanced Tools, and then click Open Performance Monitor.

The following is a summary of some important counters and what they tell you.
 
Memory, Committed Bytes: This is a measure of the demand for virtual memory. It shows how many bytes have been allocated by processes and to which the operating system has committed a RAM page frame or a page slot in the pagefile (or both). As Committed Bytes grows above the available RAM, paging increases, and the amount of the pagefile in use also increases. At some point, paging activity starts to significantly affect perceived performance.
 
Process, Working Set, _Total: This is a measure of the amount of virtual memory in "active" use. It shows how much RAM is required so that the actively used virtual memory for all processes is in RAM. This is always a multiple of 4,096, which is the page size used in Windows. As demand for virtual memory increases above the available RAM, the operating system adjusts the size of virtual memory in the Working Set for a process to optimize the use of available RAM and to minimize paging.
 
Paging File, %pagefile in use: This is a measure of how much of the pagefile is actually being used. This is the counter you should use to determine whether the pagefile is an appropriate size. If this counter reaches 100, the pagefile is completely full and operations stop working. Depending on the volatility of your workload, you probably want to set the pagefile large enough so that no more than 50 to 75 percent of it is used. If a large part of the pagefile is in use, having more than one pagefile on different physical disks may improve performance. 
 
Memory, Pages/Sec: This is one of the most misunderstood measures. A high value for this counter does not necessarily indicatey that your performance bottleneck is a shortage of RAM. The operating system uses the paging system for purposes other than for swapping pages due to memory over-commitment.
 
Memory, Pages Output/Sec: This shows how many virtual memory pages were written to the pagefile to free RAM page frames for other purposes each second. This is the best counter to monitor if you suspect that paging is your performance bottleneck. Even if the Committed Bytes value is greater than the installed RAM, a Pages Output/sec value that is low or zero most of the time indicates that there is not a significant performance problem that is caused by not enough RAM.
 
Memory, Cache Bytes
Memory, Pool Nonpaged Bytes
Memory, Pool Paged Bytes
Memory, System Code Total Bytes
Memory, System Driver Total Bytes

The sum of these counters is a measure of how much of the 2 GB of the shared part of the 4 GB virtual address space is actually in use. Use these counters to determine whether your system is reaching one of the architectural limits discussed above.
 
Memory, Available MBytes: This measures how much RAM is available to satisfy demands for virtual memory (either new allocations, or for restoring a page from the pagefile). When RAM is in short supply (for example, Committed Bytes is greater than installed RAM), the operating system tries  to keep a certain fraction of installed RAM available for immediate use by copying virtual memory pages that are not in active use to the pagefile. For this reason, this counter will not reach zero. Therefore, it is not necessarily a good indication of whether your system is short of RAM.

The following links and articles go into greater depth on these subjects:

• Microsoft® Windows® Internals, Fourth Edition: Microsoft Windows Serverâ„¢ 2003, Windows XP, and Windows 2000 (http://www.microsoft.com/MSPress/books/6710.aspx)
• AskPerf Blog: An Overview of Troubleshooting Memory Issues (http://blogs.technet.com/askperf/archive/2008/01/25/an-overview-of-troubleshooting-memory-issues.aspx)
• AskPerf Blog: Memory Management - x86 Virtual Address Space (http://blogs.technet.com/askperf/archive/2007/09/28/memory-management-x86-virtual-address-space.aspx)
• AskPerf Blog: An Overview of Troubleshooting Memory Issues (http://blogs.technet.com/askperf/archive/2008/01/25/an-overview-of-troubleshooting-memory-issues.aspx)
• AskPerf Blog: An Overview of Troubleshooting Memory Issues - Part Two (http://blogs.technet.com/askperf/archive/2008/01/29/an-overview-of-troubleshooting-memory-issues-part-two.aspx)
• AskPerf Blog: Memory Management - Demystifying /3GB (http://blogs.technet.com/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx)
• Microsoft KB Article 177415: How to use Memory Pool Monitor (Poolmon.exe) to troubleshoot kernel mode memory leaks (http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fdefault.aspx%2fkb%2f177415)
• Microsoft KB Article 294418: Comparison of 32-bit and 64-bit memory architecture for 64-bit editions of Windows XP and Windows Server 2003 (http://support.microsoft.com/?scid=http%3a%2f%2fsupport.microsoft.com%2fdefault.aspx%2fkb%2f294418)

·         http://blogs.technet.com/askperf/archive/2008/02/07/ws2008-memory-management-dynamic-kernel-addressing-memory-priorities-and-i-o-handling.aspx (http://blogs.technet.com/askperf/archive/2008/02/07/ws2008-memory-management-dynamic-kernel-addressing-memory-priorities-and-i-o-handling.aspx)

·         Intel Physical Addressing Extensions (PAE) in Windows 2000
http://kbalertz.com/268363 (http://support.microsoft.com/default.aspx?scid=kb;en-us;268363)

·         Large Memory Support Is Available in Windows 2003 and Windows Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;283037 (http://support.microsoft.com/default.aspx?scid=kb;en-us;283037)

·         A Description of the 4 GB RAM Tuning Feature and the Physical Address Extension Switch
http://kbalertz.com/Feedback.aspx?kbNumber=291988 (http://kbalertz.com/Feedback.aspx?kbNumber=291988)

·         Address Windowing Extensions
http://msdn2.microsoft.com/en-us/library/Aa366527.aspx (http://msdn2.microsoft.com/en-us/library/Aa366527.aspx)

·         PAE Design
http://www.microsoft.com/whdc/system/platform/server/pae/default.mspx (http://www.microsoft.com/whdc/system/platform/server/pae/default.mspx)

·         Memory Support and Windows Operating Systems
http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx (http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx)