[SOLVED] 500GB NVMe SSD - Fixed permanent page file vs automatically managed

[ShangWang]

Hi all,

I have 8GB of RAM, and although I should upgrade I would rather not buy another stick.

I was given advice on another thread saying that setting a permanent page file of 4096mb would be "faster" than setting my page file automatically.

It seems to be enough for running a game and a few browser tabs. The person said this would prevent a fragmented swap file and that if I wanted to change/increase the page file in the future I would:

1. Set page file to 0 and boot into safe mode
2. Set the page file again and restart normally

Is all of this information false?

Should I just set my page file back to automatically managed and I would suffer no repercussions on the system or performance when playing games whatsoever?

 

[RUSerious]

Technically, incorrect.
If you use a system managed pagefile then the pagefile size is regularly changing. This 'resizing' of the pagefile does take extra CPU and drive resources.

That's the 'old' school answer; with small slow memory and small, very slow HDDs. He has a fine SSD, the extra 'resources' required are minuscule. The best answer is the one that gets @ShangWang on his way.
@USAFRet answer does this with nothing for the OP to worry about. It's time to let this one rest

 

[SkyNetRising]

However what I'm wondering is how the SIZE of the static page file can affect performance.

Pagefile usually gets accessed in lots of random reads and smaller number large sequential writes.
The bigger the pagefile, the more time it takes to perform i/o operations. More time to find necessary location.
Even more time, if pagefile is heavily fragmented. This is very noticeable, if pagefile is placed on a mechanical HDD.

With SSDs this is not such a big problem anymore. Impact is less noticeable.
But then again - placing pagefile on SSD consumes extra SSD write cycles. You don't want that either.

 

[alceryes]

Let's say 4GB vs a 16GB page file, the ONLY resource taken up is storage and that's it if it was static?

Correct.
Note that incorrectly sizing the pagefile can cause issues. See here - https://docs.microsoft.com/en-us/windows/client-management/determine-appropriate-page-file-size
Setting a static pagefile equal in size to the amount of RAM in your system is a safe bet.

 

[ShangWang]

Correct.
Note that incorrectly sizing the pagefile can cause issues. See here - https://docs.microsoft.com/en-us/windows/client-management/determine-appropriate-page-file-size
Setting a static pagefile equal in size to the amount of RAM in your system is a safe bet.

Sounds good, but 8GB of page file is a bit too much for me, so I'm good with 4096mb. My system has never exceeded 10GB of total RAM usage ever.

 

[alceryes]

That's the 'old' school answer; with small slow memory and small, very slow HDDs. He has a fine SSD, the extra 'resources' required are minuscule. The best answer is the one that gets @ShangWang on his way.
@USAFRet answer does this with nothing for the OP to worry about. It's time to let this one rest

Regardless of whether it's 'old school' or not, what I stated is technically correct.

 

[ShangWang]

Pagefile usually gets accessed in lots of random reads and smaller number large sequential writes.
The bigger the pagefile, the more time it takes to perform i/o operations. More time to find necessary location.
Even more time, if pagefile is heavily fragmented. This is very noticeable, if pagefile is placed on a mechanical HDD.

With SSDs this is not such a big problem anymore. Impact is less noticeable.
But then again - placing pagefile on SSD consumes extra SSD write cycles. You don't want that either.

Extra write cycles, yes. However usually not a big deal, SSD will likely be replaced/die from other reasons before it reaches the end of it's write cycle life.

I believe even if I did upgrade to 16GB of RAM, windows will still make the same use of virtual memory.

Do you know approximately when windows would automatically resize the page file? Let's say you had 32 GB of physical memory and didn't even come near using 24GB of physical RAM, is it possible windows would still resize the page file regardless?

 

[hotaru.hino]

Do you know approximately when windows would automatically resize the page file? Let's say you had 32 GB of physical memory and didn't even come near using 24GB of physical RAM, is it possible windows would still resize the page file regardless?

From https://docs.microsoft.com/en-us/windows/client-management/determine-appropriate-page-file-size

By default, page files are system-managed. This means that the page files increase and decrease based on many factors, such as the amount of physical memory installed, the process of accommodating the system commit charge, and the process of accommodating a system crash dump.

For example, when the system commit charge is more than 90 percent of the system commit limit, the page file is increased to back it. This continues to occur until the page file reaches three times the size of physical memory or 4 GB, whichever is larger. This all assumes that the logical disk that is hosting the page file is large enough to accommodate the growth.

Basically it appears you have to be running out of virtual memory space (which is physical RAM + page file size) before Windows starts increasing the page file size.

 

[ShangWang]

From https://docs.microsoft.com/en-us/windows/client-management/determine-appropriate-page-file-size


Basically it appears you have to be running out of virtual memory space (which is physical RAM + page file size) before Windows starts increasing the page file size.

I see, so in the case I mentioned even if the page file was set to something extremely small like 32mb as long as physical RAM does not come close to running out, the size will not change?

 

[hotaru.hino]

I see, so in the case I mentioned even if the page file was set to something extremely small like 32mb as long as physical RAM does not come close to running out, the size will not change?

It's not the physical RAM usage that matters, it's the Memory Commit usage.

 

[ShangWang]

It's not the physical RAM usage that matters, it's the Memory Commit usage.

What if I forced that 32mb page file to remain the same? Due to memory commit usage the system could say it's "out of memory" despite having plenty of physical RAM to use and that's why setting a considerable initial is necessary?

 

[USAFRet]

What if I forced that 32mb page file to remain the same? Due to memory commit usage the system could say it's "out of memory" despite having plenty of physical RAM to use and that's why setting a considerable initial is necessary?

What if....

What if you tried various configurations, and see what works best with your hardware and software?

 

[ShangWang]

What if....

What if you tried various configurations, and see what works best with your hardware and software?

I believe the difference is miniscule but 4096mb static works for me.

I'm just wondering about how these things work in theoretical situations as I am curious.

 

[USAFRet]

I believe the difference is miniscule

That is 100% correct.

The theoretical is different for each combination of hardware and software.

 

[hotaru.hino]

What if I forced that 32mb page file to remain the same? Due to memory commit usage the system could say it's "out of memory" despite having plenty of physical RAM to use and that's why setting a considerable initial is necessary?

I explained this before.

However, never set the page file to 0. This reduces the entire memory space to just how much physical RAM you have. This is a problem because when apps request memory from the OS, the OS will always give more than necessary because chances are, the app is going to request more memory. Even if the app doesn't use the space the OS reserved for it, it can still be swapped out in case another app needs data in physical memory. It's a lot cheaper to swap out a reserved portion of RAM that isn't being used because, well, there's nothing to swap.

If you set it to 0, depending on how memory is used in your use case, you can run into an issue where an app complains the system has no more memory despite there being free space in physical memory. It's because the OS reserved the rest for other apps and the OS will not unreserve memory.

Also read https://devblogs.microsoft.com/oldnewthing/20091002-00/?p=16513

 

[ShangWang]

I explained this before.



Also read https://devblogs.microsoft.com/oldnewthing/20091002-00/?p=16513

I see, sorry about that. I thought that there might've been a difference if you set at least a very small page file.

However I'm a bit confused about what "cheaper" means.

 

[hotaru.hino]

I see, sorry about that. I thought that there might've been a difference if you set at least a very small page file.

However I'm a bit confused about what "cheaper" means.

If the OS has to swap a page that was committed to an app, but the app actually hasn't used the page, there's nothing to copy. All the OS does is update the memory address the page points to.

 

[ShangWang]

If the OS has to swap a page that was committed to an app, but the app actually hasn't used the page, there's nothing to copy. All the OS does is update the memory address the page points to.

I'm sorry I still don't understand, to copy what? You mean swapping unused RAM is cheaper because you don't have to "pay" an idle app with a page file?

 

[hotaru.hino]

I'm sorry I still don't understand, to copy what? You mean swapping unused RAM is cheaper because you don't have to "pay" an idle app with a page file?

Let me reword it:

If the OS has to swap a memory page that was committed to an app, but the app actually hasn't used the memory page, there's no data to copy to the page file because the app hasn't used the memory page. All the OS does is update the memory address the page points to. It's "cheaper" because it's not doing any data copying operation. It just updates a table already in RAM.

 

[ShangWang]

Let me reword it:

If the OS has to swap a memory page that was committed to an app, but the app actually hasn't used the memory page, there's no data to copy to the page file because the app hasn't used the memory page. All the OS does is update the memory address the page points to. It's "cheaper" because it's not doing any data copying operation. It just updates a table already in RAM.

To clarify you're saying an "app" has not been opened yet but it has a memory page assigned to it. When it is opened it then "swaps" that memory page that was unused for actual unused RAM to be utilized. Is this "data" that was supposed to be copied to the memory page the amount of RAM that it was supposed to use but didn't because it wasn't opened yet?

I'm not sure I understand the context of when this is happening but I hope this is right.

 

[SkyNetRising]

Do you know approximately when windows would automatically resize the page file? Let's say you had 32 GB of physical memory and didn't even come near using 24GB of physical RAM, is it possible windows would still resize the page file regardless?

Depends on virtual memory initial size settings and workload.

I have a PC with 32GB ram. Probably ram usage has never gone past 20GB.
Virtual memory is set to 1200MB initial, 10GB max.
It doesn't increase pagefile size. Stays on initial size all the time.
If I set it to very small size (like 16MB), then it chages size from time to time (and resets size back on reboot).

 

[hotaru.hino]

To clarify you're saying an "app" has not been opened yet but it has a memory page assigned to it. When it is opened it then "swaps" that memory page that was unused for actual unused RAM to be utilized. Is this "data" that was supposed to be copied to the memory page the amount of RAM that it was supposed to use but didn't because it wasn't opened yet?

I'm not sure I understand the context of when this is happening but I hope this is right.

Okay, let me reword again:

• User launches app
• OS assigns parts of the memory space for the app to work with
• The app requests more memory space
• The OS looks to see if there's space available for the app
• If there's free space available, the OS reserves the amount of space the app wanted, plus extra so if the app requests more memory, it's right there.
  • How much extra memory is reserved is essentially unknown, I don't know the magical formula Windows does and I'm pretty sure you won't find it documented anywhere.
• When the app accesses that memory space for the first time, it gets marked as in use.
• If the OS has to make room in physical memory space, it looks to see if it can evict/move around first before resorting to swapping out memory space that an app has accessed:
  • Data that was cached for some future use if nobody's using it. Windows preloads a lot of stuff to make app launching faster. It also doesn't immediately clear out said stuff because chances are, you might launch an app that'll use it.
  • Memory space that hasn't been accessed
• The reason it does the above is because the OS doesn't have to copy any contents of that memory space into storage, which is slow, as there's no data an app needs.

This is getting beyond the scope of the original topic. If you're interested in all of this I highly recommend reading a book on operating systems and memory management.

Otherwise, to go back to the original topic at hand: leave your page file as system managed and unless it's actually taking up more space than you'd like, don't worry about it. Any actual performance losses due to resizing or whatever is practically non-existent.