Paging File Considerations for Windows NT (and family)
Last Updated: 11 Jul 2005
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*** PLEASE NOTE: Link(s), If Provided, May Be Wrapped ***
No matter how much physical RAM you have, NT/2000/XP
always uses a pagefile. This is by design.
In order to determine exactly what size pagefile you
need, you should monitor various performance monitor
counters using the native Perfmon utility. The following
information, however, can provide you with a valid
pagefile configurations for maintaining high levels of
system performance.
PAGEFILE BASICS
Assuming that you have a current system (anything in the
past 2 years) the difference in performance between an
OPTIMAL pagefile and a less-than-optimal pagefile is not
as great as it used to be for most server functions. IMO,
if your system has sufficient RAM (say 512MB+ for desktops
and 1GB+ for servers), it is a much better use of your
time to ensure that your system is properly defragged, as
this will result in better overall performance.
Although I have come across a few (poorly written) apps
that function poorly with a large pagefile, you generally
don't suffer any sort of penalty for having a larger
pagefile than the OS requires or recommends. Additionally,
you will find that it makes things much easier when you plop
an extra 256MB/512MB/1GB of RAM into a system and you don't
need to re-adjust the pagefile size again.
If you are running a heavily used database app (Exchange
included) you will definitely need to spend more time
tuning and sizing your box as it pertains to performance
in general, and paging in particular. For most other
machines, however, you can set some guidelines that work
for you, then stick with them (consistency is a GoodThing®!)
WINDOWS USE OF VIRTUAL MEMORY
Generally speaking, your pagefile size should exceed the
amount of RAM installed in your system. This is because
of how NT and family (2000/XP/2003) allocate pages for
virtual memory, and how active pages are swapped into the
pagefile. This is explained in great detail in the
"Inside Windows NT" and "Inside Windows 2000" books by
David A. Solomon and Mark Russinovich.
The size of the virtual memory file does not contribute
to performance, per se -- not directly, anyway. The
location and fragmentation level of the pagefile play
a greater role in performance than does the size of the
pagefile. Likewise, the speed of the drive(s) containing
the pagefile, have a greater impact on system performance.
What the pagefile size does contribute to is the overall
usuability of your system. 32-bit NT (and family) provide
2GB+ of addressable space for applications. As part of the
allocation of memory for multiple, concurrent applications,
virtual memory is used to keep all sorts of information,
including program data. When an application is determined
to be inactive for a period of time, the OS seeks to move
as much of this data to disk as possible. This is referred
to as "paging", and is done to free up RAM for apps that
are currently active.
Whatever code is not marked as non-pageable (as designated
by the application developer) is periodically moved into
the pagefile. There has to be enough virtual memory (VM)
space for these paged out apps, along with the space being
used by active applications.
Because the pagefile is a static file with a definitive
starting location, it can be written to (and read from)
faster than most other files (outside of the MFT), and
is thus a better candidate for file access than searching
for program code/data somewhere else in the file system
(such as the application's own directory). This is
especially true if you've set the Initial and Max size
to be the same.
In other words, it is more desirable for your application
to load 30MB of data and dump 10MB into the pagefile for
occasional access, than to load 20MB of data and then
load/unload the other 10MB on demand.
If you have multiple hungry applications, it is possible
for several of them to need or want a substantial chunk
of the pagefile. A failure to get this space can result
in Low Memory errors (for apps with poor error handling),
or in the purging of other pages from the pagefile. This
will necessitate your system reloading these discarded
pages from disk whenever the respective application
finally gets around to requesting the data in question.
Welcome to the land of needless disk thrashing.
Two things will cause frequent pagefile churning:
• Insufficient RAM for the number of open apps
• Insufficient Pagefile size for number of open apps
You will find that graphics manipulation applications
are heavy users of the pagefile, particularly Adobe
products.
Again, you can always use Perfmon to determine the
optimal pagefile size based on your usage. 3x is the
default max for 2000 and XP. You will want to look
at the Memory and Pagefile objects in Perfmon.
PAGEFILE SIZE RECOMMENDATIONS
Here is the recommended pagefile configuration for power
users or servers with moderate-to-heavy usage (3x RAM):
Real RAM ............ Pagefile Size
(Initial & Max)
64MB ................... 192MB
128MB ................... 384MB
256MB ................... 768MB
384MB .................. 1152MB
512MB .................. 1536MB
768MB .................. 2304MB
1GB .................. 3072MB
2GB .................. 4095MB
A single pagefile is limited to 4095MB, although you can
create multiple pagefiles across multiple partitions to
obtain virtual memory sizes exceeding 4GB. If you have
more than 1GB RAM, you *really* should use PERFMON to
determine the proper pagefile size for your system. For
the most part, the more apps you run simultaneously, the
greater your paging needs are likely to be.
Remember, disk space is cheap. There are very, very few
scenarios where having a large pagefile will cause a
problem with your system, but if your pagefile is too
small, you will not be able to map virtual space for all
running processes, which will prevent you from fully
utilizing your installed physical memory.
Additionally, on a server, having a larger pagefile
affords you a little more time to detect and correct
issues with mem-leaking applications, or accomodate
any bursts of Virtual-Memory-inducing activity...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: Be sure to take this opportunity to increase your
Maximum Registry Size as well. A good number is
36-48K (Win2K defaults are higher: 48-70K).
In Windows XP and 2003, the registry size is
managed automatically.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SYSTEM RECOVERY OPTIONS
If you require the ability to produce .DMP files after
a system crash (I have not used this feature in years),
then you should ensure that you have enough space on
drive C: (at least RAM + 12MB). Otherwise, all you
need is a 2MB pagefile on C: in order to write an alert
to the NT Eventlog.
Win2K/XP allows you to have a very small kernel dump
(64K) and adds several other convenient options to the
pagefile settings.
BEST & WORST PRACTICES
If you value the performance or stability of your system,
you will avoid placing your pagefile...
...on a RAID5 partition (RAID1 is fine)
...across multiple partitions of a single, physical disk
...on a single, non-redundant drive (production servers)
...where it will become easily fragmented
In order, from MOST to LEAST desirable, you should place
your pagefile...
...across multiple, non-busy drives (not just different partitions)
...on its very own dedicated drive (with redundancy)
...on a non-busy drive where %SystemRoot% does NOT reside
...on the same drive and partition as %SystemRoot%
Unless you're one of those people that believe that more
problems equal more job security, your pagefile should
NOT be...
...split across multiple partitions of the same disk
...fragmented
...too small
For servers, always ensure that your pagefile is on some
sort of RAID drive, as you will lose your whole system
if the pagefile becomes unavailable. Thus, even though
it is performance draining and wasteful, having your
pagefile on a RAID5 partition would still be *better*
(relatively speaking) than having it on a single drive
(with regards to Uptime/Redundancy, but NOT Performance).
Also, ensure that your pagefile (along with the rest
of your drive) is defragged regularly. If you set the
Initial and Maximum sizes to the same value, you will
not incur the penalty for growing the pagefile, nor
will it become fragmented.
DISK HEAD MOVEMENT
One of the key reasons not to devote a partition to the
pagefile (unless it's on its own drive) is the resulting
movement of the drive heads. Here's a simulation:
M = Master File Table (MFT)
P = Pagefile
+ = User Disk Data
. = Free Disk Space
Here's a single hard drive with one partition:
|--------------------------C:----------------------------|
MMMMM.PPPPPP..+++++.++++++.++++.++++..++................
And here's a single hard drive with multiple partitions,
and the pagefile on a drive other than C:
|------C:------|---------------D:---------------|---E:---|
MMM.+++.+..... MMMM.++++..++..++............... MPPPPPP.
Now, look at what's involved in the disk head moving
between the pagefile and other data areas of these two
different disks. You can see where performance will be
impacted.
LEARN MORE ABOUT VIRTUAL MEMORY IN WINDOWS
More info about NT's use of virtual memory can be found
in the following books and resources:
BOOKS -- https://brainwavecc.com/Library.html
• Inside Windows NT, Second Edition
• Optimizing Windows NT
• Tuning and Sizing NT Server
• Windows 2000 Server Resource Kit
• Windows 2000 System Administrator's Black Book
• Windows NT Performance Monitoring, Benchmarking, and Tuning
• Windows NT and 2000 Answer Book
VIRTUAL MEMORY TWEAKING
If you want to ensure that Windows is less eager to
page memory to disk, you can set the DisablePageExecutive
registry setting to "1".
• http://support.microsoft.com/?KBID=184419
• http://www.tweaktown.com/document.php?dType=guide&dId=120&dPage=5
• http://is-it-true.org/nt/atips/atips95.shtml
• http://www.tek-tips.com/gfaqs.cfm/spid/616/sfid/784
PAGEFILE TOO SMALL
If you experience a "Pagefile Too Small" error, it is
very likely that it is a permissions problems (e.g. the
EVERYONE group has been removed from the filesystem, but
the SYSTEM account has not been given explicit access to
the drive in question).
Use the following commands to correct this error:
CACLS C:\ /C /E /P SYSTEM:F Administrators:F
CACLS C:\*.* /T /C /E /P SYSTEM:F Administrators:F
You only need the first one to fix the pagefile issue.
The second command is useful for ensuring that you never
lock the system itself out of any file access.
• http://support.microsoft.com/?KBID=316528
• http://support.microsoft.com/?KBID=249321
• http://support.microsoft.com/?KBID=242447
• http://support.microsoft.com/?KBID=259151
OTHER PAGEFILE ISSUES
Occasionally, when adding or removing drives from your
system, your drive letter assignments might change, and
you will receive a message that your pagefile cannot be
found, or that it does not exist. The easist way to fix
this is connect to your machine remotely and edit the
registry:
Key ...... HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Value .... PagingFiles
Type ..... REG_MULTI_SZ
If you can't access it over a network, try placing the
drive into another system and edit the registry from
there.
• http://support.microsoft.com/?KBID=168646
WHITEPAPERS & TECH DOCUMENTS
• http://www.3dspotlight.net/tweaks/memory-win2k/memory-5.shtml
• http://www.rojakpot.com/Speed_Demonz/Swapfile_Optimization/Swapfile_Optimization_01.htm
• http://www.microsoft.com/windowsxp/expertzone/columns/mcfedries/03june16.asp
• http://www.microsoft.com/windowsxp/home/using/productdoc/en/sysdm_advancd_perform_change_vmpagefile.asp
• http://www.microsoft.com/windowsxp/home/using/productdoc/en/sag_mpmonperf_15.asp
• http://support.microsoft.com/?KBID=889654
• http://support.microsoft.com/?KBID=142719
• http://support.microsoft.com/?KBID=308417
• http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/XPKernel.asp
• http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ProRK/prec_evl_bsaq.htm
• http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/Core/fnec_evl_wafw.htm
• http://www.microsoft.com/TechNet/win2000/win2ksrv/technote/perftune.asp
• http://www.microsoft.com/TechNet/prodtechnol/winntas/training/ntarchitectoview/ntarc_7.asp
• http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/maintain/optimize/building.asp
• http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/tips/w2mem.asp
• http://support.microsoft.com/?KBID=99768
• http://support.microsoft.com/?KBID=216446
• http://support.microsoft.com/?KBID=197776
• http://support.microsoft.com/?KBID=197379
• http://support.microsoft.com/?KBID=171793
• http://www.execsoft.com/tech-support/NT-articles/article.asp?F=1998012717.htm
• http://www.jsiinc.com/SUBA/TIP1000/rh1042.htm
• http://www.winnetmag.com/windowsnt20002003faq/Article/ArticleID/21793/windowsnt20002003faq_21793.html
PERSONAL NOTES
• Jul 2005: Added link to http://support.microsoft.com/?KBID=889654
• Although you can get by with little or no paging in
Win9x/ME, virtual memory usage in NT/2000/XP is very
different. Using a small pagefile and multitasking
a fair number of apps will possibly result in
"Out of Memory" errors even when lots of RAM appears
to be still available.
• NT (up to version 4.0) defaults to a max pagefile
size of (RAM + 12)
• Windows 2000/XP default to an initial pagefile size
of (RAM * 2) and a max of (RAM * 3)
• If the SYSTEM account (or EVERYONE account) doesn't
have full control on the partition where the pagefile
is going to reside, you may get "Pagefile Too Small"
errors.
• Windows XP provides an option for NO PAGEFILE, but it
will actually use a temporary one if you select this.
In any event, this option is NOT advised, and will
ultimately hamper performance. Some applications cannot
deal with it.