Optimal Window’s page file settings for SQL Server

Category: Performance
Item: Windows OS page file not optimal

What is the Windows OS page file?

This file is a form of virtual memory.

When your memory ram becomes full, Windows moves data from your memory RAM to your hard drive, placing it in the page file (also known as the swap file).

You never want your SQL Server to start paging.

SQL Server tends to go pear-shaped when it’s memory is paged to disk.

Optimal page file size settings for SQL Server

By default, the page file is auto managed by Windows.

You don’t want to trust the management of page file to Windows, as it won’t do what is optimal for SQL Server.

Page file sizing depends on the system crash dump setting requirements and the peak usage or expected peak usage of the System commit charge.

Both considerations are unique to each System, even for identical systems.

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?

It depends on the specific workload and the type of server.

When sizing the page file, we need to consider our application’s memory needs and crash dump settings.

A good point of start is set 8-12 GB size for Kernel Memory dump on System with up to 256GB RAM.

You can learn more about it here.

How can I change the windows file size?

You can configure the page file by using System Properties:

  1. Run sysdm.cpl;
  2. Go to Advanced ;
  3. Select Settings under Performance ;
  4. Go to Advanced (again);
  5. Change under Virtual Memory.
Figure 1 – Windows page file size options.


Note:
Make sure to set SQL Server max memory settings correctly.
There are some best practices on how to configure this here.

More information

Microsoft – How to determine the appropriate page file size for 64-bit versions of Windows
Microsoft – RAM, virtual memory, pagefile, and memory management in Windows

Mark Varnas

Mark Varnas

I love making performance tuning SQL Servers fast and making them more stable. And I channel that obsession into our SQL Managed Services and new content here. When I'm not writing about SQL, I spend time outside hiking, skiing, mountain biking, or trying a new recipe.

Leave a Reply

Your email address will not be published. Required fields are marked *