Modern Day Page File Planning

Introduction

Page files can have great effect on system performance and recovery in a Windows environment. Incorrect sizing can result in slow or unresponsive systems, excessive use of disk resources, and the inability to obtain sufficient information from dump files in the event of a crash. The old belief regarding proper sizing of the page file is this: irrelevant of the size of RAM, a page file must be at least 1.5 times the quantity of physical RAM installed in the server. In modern day, 64-bit computing, this page file allocation rule is no longer relevant. Configuring systems with 1.5x RAM, to support full memory dumps, will turn a small outage into a major outage, due to the amount of time it takes to write the contents of RAM to disk. Additionally, the amount of wasted space on system drives to provide for the massive page file and dump file add up quickly. This document discusses the modern-day approach for handling page files and page file sizing for the Windows operating system.

Initial Discussion

According to Microsoft there is no specific recommended size for the page file. At a high level, the page file size requirements are based on the hardware configuration, software running, and overall workload of the system. The recommendation is to monitor the performance characteristics of the system, and determine page file size based on the observed metrics. This is not an easy task, as many administrators manage thousands of Windows operating system instances. This approach requires gathering performance data from each individual system, interpreting the data, and modifying page file sizes, which requires a reboot to implement. While this approach is technically possible, a more realistic approach is to focus on the larger, more business critical workloads. Workloads such as SQL Server, Exchange, and Hyper-V are good places to start.

Application Specific Considerations

SQL Server

Systems running SQL Server generally have a large amount of RAM. The majority of the physical RAM allocated to the system should be committed to the SQL Server process and locked in physical RAM in order to prevent it from being paged out to the page file. Since SQL already manages its own memory space, this memory space should be considered “non-pagable” and not included in a calculation for page file size. If SQL is configured to allow locking pages in memory, set the SQL Server maximum memory setting so that some physical RAM remains available for other operating system processes. For SQL servers, a 2GB page file on the system drive, and 6GB file on a non-system drive seems to work best as a starting point, but mileage may vary.

Hyper-V

Per Microsoft’s Hyper-V product group: for systems with the Hyper-V role installed running on Windows Server 2012 and Windows Server 2012 R2, the page file for the parent partition should be left at the default page file setting of “System Managed.”

General Windows Servers

For the remaining systems, having a page file that is much too large compared to the actual non-locked memory space can result in Windows overzealously paging out application memory to the page file, resulting in those applications suffering the consequences of page misses (slow performance). As long as the server is not running other memory-hungry processes, a page file size of 4GB is a good starting point.

Some products or services may use the page file for reasons other than what have been discussed in this document. Some applications are not supported without a page file, to include domain controllers, certificate servers, LDS servers, systems running DFS replication, and Exchange Server.

Considerations for Page File Size

When sizing page files, it is important to remember that actual page file usage depends greatly on the amount of modified memory being managed by the system. Files that already exist (txt, dll, doc, exe) on the disk are not written to a page file. Only modified data not already residing on disk (unsaved text in MS Word) is memory that could potentially be backed up by a page file. There are a handful of items to consider when sizing page files.

Crash Dump Settings

There are three possible settings for Windows crash dumps

 

Windows Crash Dump Setting	Minimum page file size
Small memory dump	1 MB
Kernel memory dump	Depends on kernel virtual memory usage
Complete memory dump	1x Physical RAM plus 257MB

 

It is best to have a corporate standard as to how memory dumps are obtained in the event of a blue screen. Since we are focusing on higher memory workloads, which are usually more critical workloads, it is recommended to configure the system to perform a kernel memory dump in the event of a system crash. While a small memory dump provides enough data to inform on the faulting process, some stop codes involve drivers. Drivers are only listed in kernel memory dumps. Having a system configured to save kernel memory dumps ensures that all the information needed in the event of a crash is present, rather than having to increase the dump level and wait for unplanned another outage. Complete memory dumps are excessive, as disk space would then be required to hold a page file and the dump file, both of which would be the size of physical RAM.

 

With the release of Windows 2012, a new feature was introduced called “Automatic Memory Dump.” Enabled by default, this setting automatically selects the best crash dump model based on frequency of crashes. The Automatic memory dump setting at first selects the small memory dump option, which requires a page file or dedicated dump file to be at least 256K. If the system crashes, the feature selects bumps the system up to the kernel memory dump setting at startup, and then increases the minimum size of the system-managed page.

System Commit Charge and Limit

The system commit charge is the total amount of committed memory that is in use by all processes and by the kernel. It is the memory that has been promised and must have physical RAM. The system commit charge cannot be larger than the system commit limit, as the system commit limit is the sum of physical RAM and the page file. These numbers are shown in task manager.

 

If the system commit charge is steadily below the commit limit, the page file size can be reduced. This metric must be gathered after the system has been in use for some time.

Infrequently Accessed Pages

The purpose of the page file is to back infrequently accessed pages, so they can be removed from physical memory, providing more physical RAM for frequently accessed pages. This data cannot be obtained until the system is running for some time.

Additional Considerations

Page File Location

If the disk IOPS for the page file average more than 10 pages per second, Microsoft recommends that the page file be moved off of the system disk, and onto a dedicated drive. If the page file reached an average of 60 IOPS, use more than one dedicated page hard disk to obtain better performance, possibly by way of striping. The recommendation is to use a dedicated disk for every 60 pages per second of I/O activity. These numbers are based on 7200 RPM disks.

Number of Page Files

If the system is configured to have more than one page file, the page file that is first to respond is the page file that is used. It is likely that the page file on the faster disk will be used more frequently.

Calculating Page File Size

Putting all else aside for a moment, Microsoft has provided a few hard perfmon metrics to determine whether your page file is undersized or oversized.

Method 1

Four perfmon metrics can be observed to definitively determine whether the page file can be decreased, or needs to be increased.

Counter threshold	Suggest Value
Memory\\Available Bytes	No less than 4 MB
Memory\\Pages Input/sec	No more than 10 pages
Paging File\\% Usage	No more than 70 percent
Paging File\\% Usage Peak	No more than 70 percent

Using perfmon logs to collect data during typical usage, one can understand paging activity and adjust the page file accordingly.

Method 2

Note the value of Process\\Page File Bytes Peak and multiply by 0.7

Method 3

The minimum page file size can be determined by calculating the sum of peak private bytes used by all system processes, then subtract the amount of system RAM. The maximum page file size can be determined by calculating the sum of peak private bytes, and adding a margin for safety.

Conclusion

There are no hard and fast rules regarding page file sizing on systems, and the myth of sizing a page file at 1.5x the size of physical RAM is not a valid sizing guideline. Crash dump requirements, performance metrics, and free disk space are all driving factors. The only true way to properly size you page file is to monitor the usage, and make adjustments.

Reference Items

SWAP Sizing

http://stackoverflow.com/questions/2588/appropriate-page file-size-for-sql-server

Microsoft Articles

http://support.microsoft.com/kb/889654

http://support.microsoft.com/kb/2860880

Swapping vs Paging

http://www.techarp.com/showarticle.aspx?artno=143&pgno=1

 

Virtual Memory Management

http://msdn.microsoft.com/en-us/library/ms810627.aspx

Missing Complete Dump Option

http://www.sophos.com/en-us/support/knowledgebase/111474.aspx

System Commit Limit

http://mcpmag.com/articles/2011/07/05/sizing-page-files-on-windows-systems.aspx