I've read a bit about the strategy applied by Windows to paginate RAM to the pagefile. Apparently, Windows may decide to paginate to disk unused pages from the processes' working set, to ensure that there's available RAM to attend additional needs as soon as possible.

Our server runs a controlled number of processes, around 250. The memory usage of each of them is controlled, so the maximum used RAM by all of them is around 32 GB. The server has 64 GB, which is more than enough to ensure that there's no need to paginate to disk memory committed by additional user sessions and other applications we may run at a given moment (perfmon, profilers, etc...)

These processes highly stress the disks, which cause the average seconds per operation to raise to even 100ms. This slows a lot manyu operations and create bottlenecks in our system. My hypothesis is that it is possible to alleviate a bit the disk stress if we remove the pagefile. Windows should then stop paginating RAM at all. This would cause problems when there's no more RAM available, which we'll ensure that can't happen.

Is this hypothesis valid? Does anyone have tried this in a production environment?

Edit: I see that the question got downvoted. While that's fair and helps creating a quality Q&A and knowledge sharing site, it would be really good if the people that downvoted add some comments explaining why. Without feedback there's no improvement.

  • 1
    You are getting down voted because you have not defined your specific problem and what you have attempted. meta.serverfault.com/questions/3608/… What are your performance metrics and are they not being met? What makes you think paging space is a problem? What tuning have you tried in your test environment? What other people have done is not helpful for performance tuning, their environments are different from yours. Commented Dec 2, 2019 at 18:06

1 Answer 1


Paging files have a couple purposes. Backing large crash dumps. Are assumed by the cache algorithm of Extensible Storage Engine. And yes, allow larger commit limits.

Why do you think there is significant paging space I/O if RAM installed far exceeds the requirement?

Why would a few writes be harmful to a disk? Plenty of solid state disks have write endurance at hundreds of TB. Slower than DRAM, yes, but presumably paging space isn't used much if your capacity analysis is correct.

A constant size page file is more predicatable than system managed. However, if the system commit limit is exceeded, memory allocation failures will happen even if you had the disk space to prevent it.

Having a page file is probably the optimal choice. If you do have strong opinions anyway, you would not be the first to disable page files. See also on Server Fault: Use WMI to remove a page file.

  • Thanks John. Had no idea of the pagefile usage to support the crash dumps. We don't have SSD, maybe next year we can afford replacing the old SAN by an SSD SAN. In the meantime, I want to scratch any milliseconds I can. As you say, paging space shouldn't be used much, but I see a lot of disk activity in the pagefile drive... while at the same time there's plenty of RAM and our worker processes are reading and writing intensively, but using another drive... Hence I deducted, maybe wrongly, that the pagefile is being used to paginate part of working set just in case
    – Haplo
    Commented Dec 2, 2019 at 16:08
  • When the system is overloaded, every bit helps. The goal of the question was to find out whether what I was proposing made sense, and whether someone had tried it. Our system is critical, running 24x7, and I don't have the resources to set a test environment to replicate and test the approach. From what you mention though seems that the savings (a few bytes) won't make a difference..
    – Haplo
    Commented Dec 2, 2019 at 16:19
  • Not having a test environment is far more critical a problem than tuning your paging space. Unless you have a severe performance problem impacting your services you have not mentioned. Commented Dec 2, 2019 at 17:57
  • We have a test environment, but can't replicate the level of traffic and disk stress to replicate the problem. We have the same amount of read 'n write operations, and move around 500GB/day. I don't see the same bottlenecks in the test environment.I will further analyse the stress on the pagefile drive to see whether indeed it comes from the pagefile or something else... Thanks for your help John!
    – Haplo
    Commented Dec 3, 2019 at 9:45

Not the answer you're looking for? Browse other questions tagged .