Page File - The definitive guide
Today I will share with you my best practices for configuring the paging file in Windows Server 2008 and 2012.
Paging file seems to be a very popular subject, as we get questions about it all the time. Many customers are configuring the paging file incorrectly, based on outdated rules-of-thumb that are no longer apply to modern operating systems like Windows Server 2008 and above.
Memory, Paging and Paging file
Let's start with the basics: Windows memory management is based on Virtual Memory, where each process has its own private virtual address space. Windows will move the least used memory pages to a hidden file called the page file, when approaching a low memory condition.
The Page file is a special file used by Windows to store modified pages, and the process of moving pages from RAM to the Page file is called "Paging".
Page files have two primary roles:
- Physical extensions of RAM that store modified data
- Record information about the state of the system in case of a system crashes
I will explain the size requirements for each role.
Physical extensions of RAM
If your server exhausted all available RAM and you don't have a page file, applications will crash or hang because Windows is unable to allocate more memory. Even worse, In some cases Windows itself can become unstable.
Windows Commit Limit, also known as system commit, is the sum of current paging files’ size and the physical memory that Windows can use to allocate memory. For example: If you have a 16 GB RAM and a 16 GB paging file, then your commit limit is 32 GB.
The Commit Limit can be increased by either changing the current paging files` size, adding new paging files or by adding more RAM.
Crash dump size
On business-critical servers it's recommended to configure the server to capture memory dumps for analysis. Windows is using the paging file as a placeholder for memory dumps, meaning that Windows is writing the crash dump first in the page file, and then the SMSS process copies it to a different memory dump file.
This have an effect on the page file size, because it needs to accommodate all the information Windows recording during a crash, more on this later.
Sizing the paging file
The old rules of thumb (Page file size = RAM * 1.5 or RAM * 2) makes no sense in modern systems, where the logic should be: the more RAM you have, the less you need paging file.
So, how should you size your Page File?
Well, we don't have a magical value that will fit any system and any workload. It really depends on the specific workload and the type of server.
When sizing the page file we need to consider our applications memory needs and crash dump settings.
How do you know how much memory your application needs? The best way is to take a baseline.
- Run Performance Monitor (Perfmon)
- Go to Data Collector Sets\User Defined
- Right click on User Defined and select New
- Select Create Manually and next
- Check Performance counter
- Add the following counters:
- Memory\Committed Bytes - Committed Bytes is the amount of committed virtual memory, in bytes.
- Memory\Committed Limit - Amount of virtual memory that can be committed without having to extend the paging file
- Memory\% Committed Bytes In Use - Ratio of Memory\Committed Bytes to the Memory\Commit Limit
Note: Make sure you collect the information over a long period (one week at least), and the server is running at peak usage.
The page file size formula should be:
(Max value of Committed Bytes + additional 20% buffer to accommodate any workload bursts)-RAM size
For example: If the server has 24 GB RAM and the maximum of Committed Bytes is 26 GB, then the recommended page file will be: (26*1.2)-24) = 7.2 GB
What about the second factor: the size we need to record information when the system crashes?
The size of the memory dump is determined by it's type:
- Complete Memory Dump RAM Size + 257 MB
- Kernel Memory Dump The amount of kernel-mode memory in use (on 32-bit maximum is 2 GB, on 64-bit the maximum can go up until 8 TB)
- Small Memory Dump 64KB – 512 KB
In most cases the Kernel Memory Dump is good enough for root cause analysis, as Complete Memory Dump is only required in specific cases, for example you want to see what happened in the user mode.
From my experience, the size for Kernel Memory Dump is usually the following:
- On System with up to 256GB RAM = 8-12 GB size for Kernel Memory dump
- On System with up to 1.5TB RAM = 8-32 GB size for Kernel Memory dump
However, these numbers are NOT a Microsoft official recommendation, and may be different on your servers so always test before you apply.
Where to put the page file?
Starting from Windows 2008 and above you can place the page file on any partition, not just the system partition.
From the performance perspective you would benefit only if Windows is using the page file extensively (Commit Bytes is greater than the size of RAM).
Beside performance, disk snapshots and disk replication are also good reasons to move the page file to another partition on a different disk.
In this case you can consider moving the page file to another partition, just make sure the partition is running on a different physical disk (spindle), not on different partition on the same disk.
Configuring the page file settings
You can configure the page file by using System Properties:
- Run sysdm.cpl
- Go to Advanced
- Select Settings under Performance
- Go to Advanced (again)
- Select Change under Virtual Memory
Let's explore the different options:
- System managed – This is the default option and recommended by Microsoft
- Custom Size – Allows you to manually configure the size of the paging file
- No paging file – Configure the system for not having a page file
When using System Managed, Windows determines the size of the page file based on the amount of physical memory:
- Less than 1 GB of RAM
- The minimum size will be 1.5 * RAM, the maximum size will be 3 * RAM
- 1 GB of RAM or more
- The minimum size will be 1 * RAM, the maximum size will be 3 * RAM
On 32-bit systems the maximum size of the page file will be 4 GB, a relatively small size on modern systems. On 64-bit systems, for example an SQL server with 128 GB of RAM, the maximum page file size will be 384 GB. That doesn't mean that Windows will generate automatically 384 GB file, just if the system need this amount of Virtual Memory.
System Managed is the default option, and while it allows you to run the system without worrying about the size of the paging file in most situations, there are two potential issues:
- Disk Space – On systems with loads of RAM the page file size will be huge
- Page file Fragmentation – If the paging file expands and shrinks it can cause disk fragmentation and poor performance
This is the reason I usually recommend to manually configure the paging file on this kind of servers (High amount of RAM).
Starting from Windows 2012 there is a new behavior that designed to reduce the size of the paging file on systems with a large amount of RAM. When using System Managed and Automatic memory dump is enabled (by default) the maximum size will still be 3 * RAM, but the minimum size will be determined by several factors, such as size of RAM, committed memory history and free disk space, resulting in a much smaller paging file (less than 1 GB usually).
No paging file
As we discussed there is no need to disable the page file, even if your server has plenty of RAM.
There are two additional special cases regarding the need for page file:
- Application requirements: Domain Controllers, DFS Replication, Certificate and ADAM/LDS Servers are not supported without a page file.
- Guest VM with Dynamic Memory enabled (Hyper-V) : Dynamic Memory requires that the VM will have a page file
As always voice your opinions and ideas in the comments