Summary
This article contains basic information about the virtual memory implementation in 32-bit versions of Windows. This information concerns Windows 2000, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. (Because Windows Server 2008 R2 is available only in a 64-bit version, this information does not apply to it.)
More Information
In modern operating systems such as Windows, applications and many system processes always reference memory by using virtual memory addresses. Virtual memory addresses 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 being used, even when the memory that is required by all running processes does not exceed the volume of RAM that is installed on the system.
Processes and address spaces
All processes (for example, application executables) that are running under 32-bit versions of Windows are assigned virtual memory addresses (a virtual address space), ranging from 0 to 4,294,967,295 (2*32-1 = 4 GB), regardless of how much RAM is actually installed on the computer.
In the default Windows configuration, 2 gigabytes (GB) of this virtual address space are designated for the private use of each process, and the other 2 GB is shared between all processes and the operating system. Typically, applications (for example, Notepad, Word, Excel, and Acrobat Reader) use only a fraction of the 2 GB of private address space. The operating system assigns RAM page frames only to those virtual memory pages that are being used.
Physical Address Extension (PAE) is the feature of the Intel 32-bit architecture that expands the physical memory (RAM) address to 36 bits. PAE does not change the size of the virtual address space (which remains at 4 GB), but just the volume of actual RAM that can be addressed by the processor. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
268363 Intel Physical Addressing Extensions (PAE) in Windows 2000
The translation between the 32-bit virtual memory address that is used by the code that is running in a process and the 36-bit RAM address is handled automatically and transparently by the computer hardware according to translation tables that are maintained by the operating system. Any virtual memory page (32-bit address) can be associated with any physical RAM page (36-bit address).
The following list describes 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 | 64 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 for most practical purposes, virtual memory is unlimited. There can be many processes, and each process has its own 2 GB of private virtual address space. When the memory being used by all the existing processes exceeds the available RAM, the operating system moves pages (4-KB pieces) of one or more virtual address spaces to the computer’s hard disk. This frees that RAM frame for other uses. In Windows systems, these “paged out” pages are stored in one or more files (Pagefile.sys files) 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
System Properties (click Advanced, click Performance, and then click the
Settings button).
Users frequently ask "how big should I make the pagefile?" There is no single answer to this question because it depends on the amount of installed RAM and on how much virtual memory that workload requires. If there is no other information available, the typical recommendation of 1.5 times the installed RAM is a good starting point. On server systems, you typically want to have sufficient RAM so that there is never a shortage and so that the pagefile is basically not used. On these systems, it may serve no useful purpose to maintain a really large pagefile. On the other hand, if disk space is plentiful, maintaining a large pagefile (for example, 1.5 times the installed RAM) does not cause a problem, and this also eliminates the need to worry over how large to make it.
Performance, architectural limits, and RAM
On any computer system, as the load increases (the number of users, the volume of work), performance decreases, but in a nonlinear manner. Any increase in load or demand, beyond a certain point, causes a significant decrease in performance. This means that some resource is in critically short supply and has become a bottleneck.
At some point, the resource that is in short supply cannot be increased. This means that an architectural limit has been reached. Some frequently reported architectural limits in Windows include the following:
- 2 GB of shared virtual address space for the system (kernel)
- 2 GB of private virtual address space per process (user mode)
- 660 MB of system PTE storage (Windows Server 2003 and earlier)
- 470 MB of paged pool storage (Windows Server 2003 and earlier)
- 256 MB of nonpaged pool storage (Windows Server 2003 and earlier)
This applies to Windows Server 2003 specifically, but this may also apply to Windows XP and to Windows 2000. However, Windows Vista, Windows Server 2008, and Windows 7 do not all share these architectural limits. The limits on user and kernel memory (numbers 1 and 2 here) are the same, but kernel resources such as PTEs and various memory pools are dynamic. This new functionality enables both paged and nonpaged memory. This also enables PTEs and session pool to grow beyond the limits that were discussed earlier, up to the point where the whole kernel is exhausted.