Applies to: Windows Server 2003/R2, Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012
In forums every now and then people ask questions about setting up page files on Windows Servers, Minimum disk size for OS partition and their best practices. Hence
I thought of writing my views in this Wiki article !
If you are reading this article I presume that, you might know What is Pagefile in Windows and why that is needed etc..., I am not going to write the stuff
which can be searched and found easily.
*** Here are the best practices which I follow, they are NOT Microsoft Recommendations !!! ***
As a best practice, you need to set page file "1.5 times" the RAM or memory available on any Windows Servers.
Servers hosting Databases or resource hungry applications like SAP are recommended to have page file set "3 times" the the RAM or memory available.
Also, it is recommended to split page file on two different drives (Preferably on two different Physical/Virtual Disks) on the server
for better disk I/O performance.
For Windows Server 2003,
OS (C drive) partition size should be set as 40 GB irrespective of OS version (Std, Ent etc…) and platform (32bit or 64bit) and C drive should have
4 GB page file.
For Windows 2008, Windows Server 2008R2 and Windows Server 2012, OS (C drive) partition size should be set as
66 GB irrespective of OS version (Std, Ent etc…) and platform (32bit or 64bit) and
C drive should have
6 GB page file.
Is it OK to split page file ? Is that an recommended approach ?
Answer is Yes !
Now a days, usually servers have more than 16 GB RAM in an Enterprise level setup.Here is an example with which I would try to explain how you can split the page file.
Say, you have 16 GB RAM on a server, 1.5 times the RAM 16 GB = 24 GB; you need to set 24 GB Page file on the Server.
Now, how would you distribute the page file ? Here is the way,
You need to create a separate Drive (Let's say drive P) and split the Page file (other than the preset page file on C drive).
For Windows Server 2003, C drive already has 4 GB, now on a newly created drive P, set 20 GB page file (i.e. 24 - 4=20 GB), make sure you have at least 25 GB "P" Drive to accommodate 20
GB page file.
For Windows 2008, Windows Server 2008R2 and Windows Server 2012, C drive already has 6 GB, now on a newly created drive P, set 18 GB page file (i.e. 24 - 6=18 GB), make sure you have at least
23 - 25 GB "P" Drive to accommodate 18 GB page file.
What is the recommended size for page file if server has 128 GB or 256 GB or 512 GB or 1 TB RAM ?
Theoretical answer is, page file should be 1.5 times the RAM available on server however, practically it's not always feasible to set huge amount of page file on server as it requires very
large disk space. For the
server's with heavy amount of RAM, you might want to
limit the Page File size equal to 128 GB
P.S. You may choose OS partition size as more than 66 GB as well such has 70 GB or 80 GB. However, pagefile calculations
remains the same.
Hope that helps.
- End of the article -
What is the Page File for anyway?
Learn Best Practices for Optimizing the Virtual Memory Configuration
Adjusting Paging File Size - Old article however, contents are still relevant !
What are the maximum and minimum pagefile recommendation for Windows server 2008
The free space of C Drive is gradually decreasing daily
Windows Server 2012 - Page File Recommendations
Page File Configuration Settings Best Practices
Best Practice : Page File Management
pagefile best practice
Windows 2008 R2 Paging File Best Practice
Gold Image Build setting question
Thanks Ravikumar :-)
I have observed one behavior on windows 2008 R2 relates to pagefile.
Earlier pagefile was configured as 1.5 GB on the C-drive as system was having 1 GB RAM.
Now I have splited the pagefile between C & D-drive as 500 MB to C-drive & 1 gb on D-drive & i rebooted the server to take effect.
But in reality when i verified the pagefile.sys was present on the C-Drive of the server & when i verified on the D-drive there is no pagefile.sys file.
I am also getting errors from SCOM in monthly reports that these servers are highly using the pagefile please increase the pagefile.
Please share your thoughts on it, as it seems to be problem to me...
I commented on the thread which you have created on forum
Thanks Livio :-)
Paging on a server is not a productive thing to do - paging means dramatic loss in performance.
The idea behind the so-called 'best-practice' of 1.5x RAM has its roots in the 1990's when RAM was very expensive. This was not a best-practice in those days, it was a necessity.
If your server is paging, either you are running too many things on it, or your server is not correctly sized and needs more memory.
The real Gregski - Thanks for the comment. I am not in agreement with your views.
Do you have any evidence or justification for your comments ? If you do have, would you mind sharing that here ?
Santosh Bhandarkar, I have tried to be as concise as possible in my original comment, which includes a brief justification. As for evidence, I am sure that you can perform your own volume and performance testing to demonstrate this. I will however attempt to elaborate on this a little more:
When designing a system, each component needs to be designed according to the required specification:
a) what services a server should provide (e.g. is it single or multi-roled)
b) what resources do these services consume (e.g. CPU, RAM, I/O)
c) what is the profile of resource usage over time and volume by these resources (e.g. user count, database size, temporal issues such as memory leaks)
From these, the designer should be able to determine the minimum requirements of a system to meet the performance requirements of the user.
So the statement provided in the original post is not a best practice. In fact, it is a dangerous statement to make for a number of reasons:
1) It completely disregards sensible design principles that should be used to guide and constraint the solution
2) it introduces unnecessary configuration into the system (i.e. if sized correctly, the system will not swap)
3) it potentially introduces unintended but significant consequences on entire and unrelated subsystems (e.g. consider the impact an undersized system will have when it starts swapping to SAN)
4) it teaches young and pliable people to blindly follow a routine without them understanding the consequences
Notwithstanding that, there are numerous reasons for why a swap file might be required: SAP for example, on start up, requires a large amount of RAM to set up its internal structures, and once finished with the working space, largely never requires it again.
Staying with this example, assume your SAPS figures suggest 32GB of RAM, you will configure 48GB of swap, right? No, that is not necessarily the case, let's see:
If you do not have a 5-nines availability requirement, then go with the SAPS figures, or even possibly less because you don't care about the prolonged boot time.
If you do have a 5-nines availability requirement, you want your service back as fast as possible (after maintenance for example) - you might think about upping your RAM, let's say to 64GB. Does that mean you now configure 96GB swap? No it doesn't, it means that you can probably get away with 16GB of swap and you get a much quicker boot up. You've paid extra because your requirement dictated so
The point above is this: what is your requirement? Don't blindly configure something without understanding whether you need it, or what impact it will have.
The real Gregski, Thanks for the elucidation. However, I'll still stick to my opinion. We can debate on this aspect endlessly but I am sure we won't reach to a common conclusion ;-)