he page file is one of those pieces of the operating system that administrators know that they need to have - but they can't always explain why they need it, or how to accurately size it. Since Windows 95, Windows-based operating systems have used a special file that acts as a sort of "scratch pad" to store modified pages that are still in use by some process. Page file space is reserved when the pages are initially committed, however the page file locations are not chosen until the page is written to disk. So, in simplistic terms, the page file is used by Windows to hold temporary data which is swapped in and out of physical memory in order to provide a larger virtual memory set.
When the system boots up, the Session Manager process determines the list of page files to open by reading the value in the HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles. This value contains the name of the paging file as well as the minimum and maximum size of each paging file. Windows supports up to 16 page files. On a 32-bit system running the normal kernel, the maximum size of each page file is 4095 MB. On x64 systems and x86 systems with the PAE kernel, the maximum page file size is 16 terabytes (16TB). On IA-64 systems, each page file can be as large as 32 terabytes.
To view the list of page files, you can either look at the HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles registry value. The paging file configuration settings are managed through the System utility in Control Panel. Below are two examples of page file settings:
In the example above, the page file size is being managed by the Operating System. As you can see from the registry entry, there is just an entry for pagefile.sys - no drive letter or page file size is specified. Contrast this with the example below on a system where the page file has been statically configured:
As you can see, the registry entry in the second example has both a discrete path name for the paging file and also specific size parameters. Once a page file has been opened, it cannot be deleted while the system is running because the System process maintains an open handle to each page file on the system. That is why any changes made to the paging file configuration require a system reboot.
If there are no paging files specified, a Windows 2000 system will create a default 20MB page file on the boot partition. On Windows XP and Windows Server 2003 systems, this temporary paging file is not created. This means that the system virtual memory commit limit is based on the available memory. If the system is managing the page file size on Windows XP or Windows Server 2003, the size of the default page file is determined by the amount of physical memory, as shown below:
| System Memory | Minimum Page File | Maximum Page File |
| < 1GB | 1.5 * RAM | 3 * RAM |
| > = 1GB | 1 * RAM | 3 * RAM |
Therefore, on a 32-bit system with 512MB of RAM, the page file size would range from 768MB to 1536MB. On a 32-bit system with 2GB of RAM, the page file size would range from 2GB to 4GB (remember that 4GB is the maximum size of a page file on 32-bit operating systems). However, now consider a system managed page file on a 64-bit server with 32GB of RAM. The page file size would range from 32GB to 96GB! This is why understanding the performance of your server is so important. Although there are general recommendations about page file sizing that are based on the amount of physical RAM in a system, this is not 100% valid. If you think about it, the more memory you have, the less likely you are to need to page data out.
The page file needs of an individual system will vary based on the role of the server, load etc. There are some performance counters that you can use to monitor private committed memory usage on a systemwide or per-page-file basis. There is no way to determine how much of a process' private committed memory is resident and how much is paged out to paging files.
Committed Memory and Page File Performance Counters
| Performance Counter | Description |
| Memory: Committed Bytes | Number of bytes of virtual memory that has been committed. This does not necessarily represent page file usage - it represents the amount of page file space that would be used if the process was completely made nonresident |
| Memory: Commit Limit | Number of bytes of virtual memory that can be committed without having to extend the paging files. |
| Paging File: % Usage | Percentage of the paging file committed |
| Paging File: % Usage Peak | Highest percentage of the paging file committed |
So with this information in mind, what's the best way to determine the correct page file size? The first thing is to gather a baseline. Set up a page file that is statically sized to 1.5GB of RAM. Then monitor the server using Performance Monitor over a period of time. Ensure that the peak usage times of the server are monitored as this is when the server will be under the most load (for example, month-end / year-end processing etc). Using the information from the counters above and also examining the Peak Commit Charge number in Windows Task Manager (shown below) will give you an idea how much page file space would be needed if the system had to page out all private committed virtual memory.
So with this information in mind, what's the best way to determine the correct page file size? The first thing is to gather a baseline. Set up a page file that is statically sized to 1.5GB of RAM. Then monitor the server using Performance Monitor over a period of time. Ensure that the peak usage times of the server are monitored as this is when the server will be under the most load (for example, month-end / year-end processing etc). Using the information from the counters above and also examining the Peak Commit Charge number in Windows Task Manager (shown below) will give you an idea how much page file space would be needed if the system had to page out all private committed virtual memory.
If the page file on the system is too large, the system does not use it any more or less. In other words, increasing the size of the page file unnecessarily does not change the system performance - it just means that the system has more nonshareable committed virtual memory. If the page file is too small on the other hand, you may see error messages such as the "system is running low on virtual memory".
Remember however, that you should also check whether there is a process that is leaking memory or a pool memory leak as those will also cause error messages relating to system resources and virtual memory to be displayed.
So finally, a quick word on system-managed versus statically defined page files. Some administrators will allow the system to manage the page file sizes. However, while this ensures that you are unlikely to encounter page file related resource depletion, it can lead to severe disk and page file fragmentation as the page file continuously shrinks and expands to keep up with the needs of the system. If you are in a situation where there is severe disk fragmentation and you have a dynamic page file, I would strongly recommend reconfiguring the server with a static page file. You will also want to make sure that the disk is properly defragmented. To do this, you will need to schedule an appropriate maintenance window for your server. Then modify the page file settings on the server so that there is no page file defined. Reboot the server for the change to take effect and then defragment the disk as you normally would. Once the defragmentation process is completed, reconfigure the page file to the appropriate static size (same minimum and maximum values) and reboot the server again.
