Thoughts from the EPS Windows Server Performance Team
The 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:
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
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.
OK - that will do it for this quick look at the basics of the page file. Until next time ...
- CC Hameed
i have a windows 2000 and my virtual memory is too low, and can not figure how to fix it by what i have read. please help, someone.
Very good and informative article... i have read a lot of articles but none as clear on page files as this... Thanks
Good post, one of the areas I've heard argued over the years is where the page file should be stored and why. The first arguement is that the page file should be on a different hard drive or spindle from the OS for best performance of both, and the second is that the page file, at least 1.5 system memory should be on the boot drive with the OS to ensure that on a system crash a valid dump file can be obtained. What's the current thinking and is it different depending on the OS?
Responding to Tim Walsh, the answser is: it depends. Placing a pagefile (or pagefiles) on a separate physical disk (or disks) from the OS potentially can yield better performance, but that really depends on what the disks do. We have seen plenty of cases where having the pagefile on C: contributed to OS performance issues of one kind or another, especially in a case where the pagefile was having to grow while the system was under load. Conversely, you are right on your second point also. In order to catch a full memory dump in the event of a bugcheck does require you have a pagefile on C: that is at least as large as your physical RAM amount. However, you can get by with a much smaller pagefile on C: under most circumstances, since in most bugcheck scenarios a simple kernel dump is sufficient to debug the issue and a full dump is not generally needed.
Hi, I have Win 7 Ultimate (64X) on my laptop with 8GB RAM and 2 500GB HDD.
Now considering that it is a fair bit of RAM and hopefully I would not run out of physical RAM running any app, Would I still gain any performance to move my pagefile to the secondary HDD.
Also because it is a laptop, when I am running on a battery, would having page file on a secondary HDD use more battery power. (Because I assume if 2nd HDD is not used all the time it will go to idle mode and use less battery, maybe, not sure)
Any thoughts?
Excellent article but I feel I should have known more about this long ago. I have tried to cut pagefile down from 1.5GB to 0.5GB in order to ghost my harddrive to one DVD only. I'm running win2k with office, norton, itunes, windows media player, dvd writing, etc. etc. on 2.4 pentium with 1GB of real RAM and its only using 257MB.
So I should be ok?
We'll see.
How many GB of RAM does SBS 2008 with Exchange 2007 require?
also
Would setting a page file to an SSD or USB flash drive be ok? Recommended?
Great article !
I have referred this in my Wiki article "Best Practices for setting up Page File and Minimum Drive Size required for OS partition on Windows Servers"
social.technet.microsoft.com/.../13383.best-practices-for-setting-up-page-file-and-minimum-drive-size-required-for-os-partition-on-windows-servers.aspx
I have enough ram installed and get better performance not paging to disc. If I run out of ram it can read from my HDD without having to perform any excess write cycles. If you ask me it makes your HDD run slower right when you are very busy and just not needed like it was back in the NT4 days when RAM was expensive. Just my opinion YMMV.
one server showing paging mostly very high,
then we check in permon graph will be reaching 100% some times
can we reduce that