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
PingBack from http://www.ditii.com/2007/12/14/what-is-the-page-file/
Every day is a school day, and this make some light reading for a Monday Morning. Time to start up perfmon
Can you explain the difference between 'VM Size' and 'Mem Usage' as it is displayed in Windows 2003 Task Manager (Processes Tab)?
Nice, informative post. Keep up the good work!
Great post. Can we have a "part 2" of this with more on "when can we disable page file", "is it used by kernel...ever?", "why do we need page file to create a crash dump", "Why C drive? or why not?"
How many page files we must have to be sure that we have the best possible performance?:
I mean, for example, if we have 2 Hard Disk Drive, does that mean that we must have 2 page files on each drive, and where we must put them? - on the first partition or near it on every HDD or where, to achieve best performance?
Thank you in advance!
With best regards,
A very good post. Something I've searched for a long time.
I would also like to see a PART 2 story. I could use some more background info on large files on x86 PAE systems.
Thanks for a informative post. During a case we had with Microsoft Product Support about W2K3 terminal server performance, we was told that they recommended to use System Managed Size (we was running with a fixed pagefile on 1.5 x 8gb RAM = 12 gb pagefile).
Does this only apply to terminal servers - or do you not agree with what we was told then?
I would disagree with leaving a dynamically sizing page file on the servers as the effects of the page file constantly growing / shrinking could cause adverse affects due to file / disk fragmentation.
In the post, we provided a means to figure out how to size your pagefile - if you are not planning to increase server load in the short-term, I would strongly recommend getting some performance monitoring data set up to determine what the page file should be set at. The guideline we provided indicates that you should start with 1.5x RAM and then use the Perfmon data to determine the correct sizing.
Ultimately, as the administrator, you will understand your server roles / load the best. Performance monitoring and tuning is an ongoing activity - especially as the role of the server changes, new applications are added, new users etc.
Hope this helps!
- CC Hameed
This helped out tremendously! I now understand what that darn file is used for. On top of that, I also found out Disk Keeper's defrag program is a piece of junk. I have 40% total fragmentation and 75% of that being files.
When addressing system performance issues, a key element that is often overlooked is Disk Fragmentation
Defrag, Defrag, Defrag!
You missed the most important thing about Defrag.
Startup in SAFE MODE!
Less VXD's and Less O/S files opened = fewer im-moveable files.
Gives you a more contigious data arrangement and more contigious fee space or available space for PAGEFILE.SYS
The way to avoid fragmentation is to use a separate partition that only has the page file on it. If you really want to increase your page file speed, create use a striped partition on two or more separate disks.
How would you size a page-file for this?
DL785, 128GB ram, 4 procs, 16 cores.
SQL 2005 (reporting server)
Clustered with an identical system in an active/active cluster.
Left this out... 2 instances, performing ETL/DW type functions. OS is x64, Enterprise...