in message
There is a general "Rule" that the Pagefile should be 1.5 times
physical
RAM. However, the base size needs to equal Physical RAM to do a
Full Memory dump.
Actually the base pagefile size should be equal to the physical RAM
size plus 64KB. This limitation is superfluous if you configure
Windows to NOT save a dump, even a small one, when it crashes. This
is not related to the 64KB size for the smallest size selectable for a
crash dump logfile. I can't remember why I include this extra 64KB
but it's something that has stuck with me for years of doing QA
testing on multiple Windows platforms.
Actual usage varies according to what you use &
how much RAM it requires. With current PCs having 1.0 Gigabytes or
more you'll find that the Pagefile traffic is just around ~50-75 Meg
with
normal use.
I use the general rule of setting pagefile space:
- For 256MB, or less, set the minimum pagefile size to 384MB.
- For more than 256MB but less than 1GB, set the minimum pagefile size
to 1.5 times the size of physical RAM.
- Above 1GB, set maximum pagefile size to 1 times the size of physical
RAM.
- These defaults may be overridden if you use an application that
wants LOTS of pagefile space. Most end-users don't run
enterprise-level applications on their workstations so this rarely is
a need.
- If there are multiple hard disks, split the pagefile across those
hard disks (at 1 times the size of the physical RAM for the pagefile
on each hard disk). The partition must obviously not be hidden for
Windows to use that pagefile. Use only one pagefile in one unhidden
partition per hard disk. This helps performance because Windows will
first attempt to use pagefiles in partition on hard disks other than
the partition in which Windows is installed to permit overlapped I/O
to those hard disks. It is possible to allocate a tiny pagefile in
the Windows partition and just use the pagefiles in the other
partitions for virtual memory but I recommend the 1x size in case you
later lose the other hard disk(s). Do not place multiple pagefiles in
different partitions on the same hard disk.
- If you enable dump file logging on a Windows crash, add 64KB to the
minimum size. Unless you are a developer debugging your own
application that crashes, the crash dump is rarely requested by
technical support (they usually don't know what to do with it). Users
don't know what to do with the dump logs. On my work host, crash
logging is enabled (complete memory dump). At home, it is disabled
(none).
Often I use a simpler algorithm: 1.5x for under 1GB of RAM, 1x for 1GB
and up, set minimum = maximum for the pagefile size, and disable crash
dump logging.
You can move it, resize it, defrag it and all other kinds of tweaks
but
it's easiest to just let Windows manage it.
Actually you will want to set the minimum and maximum pagefile size to
the same value to reduce fragmentation of its file space on your hard
disk. Set min and max to the same value and reboot to use the new
values. However, to remove any defragmentation already present in the
pagefile.sys file, you will need to use a defragmenter that will touch
that file, like SysInternals' PageDefrag (free). There is another
trick of deleting the pagefile.sys file by rebooting into Recovery
Console mode, unhiding that file, renaming it to something else, and
then deleting it, and reboot back into Windows.
If you let Windows manage the pagefile size between two different
values for minimum and maximum size, the pagefile is more likely to
get defragmented. With minimum = maximum, there will probably be 2 or
3 fragments for the pagefile but it won't get worse over time.
Some "Performance" sites
recommend turning it off but that works against the design of a
Virtual
memory system.
Even if you had a terabyte of physical RAM, some pagefile space is
always used by the OS and your applications. Applications may not
function if there is no pagefile space (i.e., you have gobs of
physical memory and set max size of the pagefile to zero). Even
Windows might not run since it expects to put part of its Exec into
the pagefile (which can be reduced with a registry tweak but not
completely eliminated). Some applications know that their data
sections or some code should be pushed into the pagefile because the
performance of the application is not impacted by using the pagefile
and they don't want to consume more physical RAM than they really
need.
An application may easily ask for hundreds of megabytes of storage
(which goes through the Virtual Memory since Virtual Memory is always
in operation even if the pagefile min and max are set to zero). Most
users never see this. Include the VM Size column in the Processes tab
of Task Manager. For example, I've seen some user proclaim that a
particular anti-virus product has less memory consumption than some
other anti-virus program that they want to pan but they never bother
to check the TOTAL memory consumption by checking how much pagefile
space is consumed by their favorite anti-virus program. You might see
in Task Manager that your favorite program only consumes 10 to 20 KB
of physical memory (under the Memory Usage column) but neglect to see
that it eats up another 150MB in the pagefile. They don't realize
their favorite program is a pig on memory consumption because most of
the data and some of its code remains dormant until the active stub
needs it. I've seen security suites that include privacy protection
mechanisms, like site blocking, where the configured table of blocked
URLs and sites is data that gets loaded into the pagefile and eats up
100 to 150 MB just for that table.
http://support.microsoft.com/kb/555223
http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm
http://smallvoid.com/article/windows-page-file.html