Share via

Windows Servers: Page file sizing considerations for Windows Server with a large amount of RAM

  • Article

Applies to

Windows Server 2003/R2, Windows Server 2008, Windows Server 2008 R2 and all versions of Windows Server.

Context

This article is addressing Windows Servers with larger amounts of RAM.

Content

As a best practice, allow enough free disk space on the system partition after installing the operating system for a page file that meets your needs.

In the article, How to determine the appropriate page file size for 64-bit versions of Windows, there are effectively two considerations to consider for page file sizing on Windows Server.

  1. The page file must be large enough to accommodate the server's system bug check (BSOD) setting. Otherwise, the system may not be able to produce a memory dump.
  2. The system commit limit (RAM + PageFiles) must be large enough to accommodate the peak usage of system committed memory usage. 

Note: Page file sizing based on 1.5 times RAM is *not* proper advise. That is a "shot in the dark" from the days of Windows NT Server. 

If drive space is very limited, then:

  1. Follow the consideration rules above. 
  2. Consider smaller system bug check settings such as None, small, or Kernel memory dump depending on how much free space is available, but keep in mind that the smaller the crash dump, the less information is available to identify the cause.
  3. Move the page file(s) to other disk drives.

If the server has a large amount of RAM, does it need a page file?

That depends on if you considered rule #1 and rule #2 above. Windows and Windows Server can run without a page file, but during system bug check, the system writes its memory to the page file and then renames the page file to memory.dmp. If the server is set to no page file, then it cannot create a dump file. The benefits of this setting is that when the server bug checks, it skips the writing of the crash dump and immediate starts rebooting. If this is the behavior you want, then go ahead, but you will not know what caused the crash in the first place. If you set it to small memory dump, then a page file at least a few megabytes is needed. Again, follow rule #1. 

Also, consider rule #2. If the system commit charge (\Memory\Committed Bytes) is often greater than the size of RAM, then a page file is needed.

The formula for page file sizing for system committed memory (Rule #2):

RAM + PageFile(s) > System Commit Charge Peak

It really is that simple. The problem is that most system administrators don't take the time to know what the system commit charge peak is on their servers. This value must be monitored on a regular basis. Otherwise, the system will be unable to make memory allocations which can lead to system instability and service failures.

Example: Large amount of RAM and no page file

Assuming Rule #1 (crash dump consideration) is not involved here or you don't want memory dumps. Let's say the server has 10 TB (terabytes) of RAM) and my system commit charge peak (\Memory\Committed Bytes) never gets higher than 4 TB. Then, the server does not need a page file.

RAM = 10 TB

PageFiles(s) = 0 TB

System Commit Charge Peak = 4 TB

RAM + PageFile(s) > System Commit Charge Peak

10 TB + 0 TB > 4 TB

This is true and therefore file.

Advantage 

  • Quick reboots
  • No disk space consumed by a page file

Disadvantage

  • Unable to create a system crash dump during a bug check, therefore unable to know why the server crashed
  • Increases the risk of running out of system committed memory which can lead to system instability, service delays, and service failures.

Example: Large amount of RAM and a very large page file

Assuming a server with a large amount of RAM (10 TB) and you followed the 1.5 x RAM misinformation. This misinformation would create a page file of 15 TB. The system commit limit is RAM + PageFile(s), so that would be 25 TB. While that sounds high, you have to consider Rule #2, does the system commit charge (\Memory\Committed Bytes) get close to the system commit limit (\Memory\Commit Limit). 

System Commit Limit = RAM + PageFile(s)

The System Commit Limit must always be larger than the System Commit Charge.

System Commit Limit > System Commit Charge

Therefore:

RAM + PageFile(s) > System Commit Charge

RAM = 10 TB

PageFile(s) = 15 TB

System Commit Charge Peak = 5 TB

In this example:

10 TB + 15 TB > 5 TB

Therefore, the page file is too large and is just taking up space on the hard drive.

Advantages:

  • The system is able to accommodate a Complete memory dump which is the best kind of dump to get when troubleshooting the cause of a system crash.

Disadvantages:

  • Considerable disk space is wasted