Copy from What is the Page File for anyway?
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
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
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
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
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
|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
|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
|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
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 …