Multiple Page Files Windows 7

[emp1re]

Guys, I'd like to hear your .02 cents on this.

I am interested to know if having multiple page files will speed performance for my win7 machine. I have a medley of drives SSD/HDD and was thinking about creating multiple page files.

My system is as follows:

A: - SSD - Page file (2 SSDs RAID 0)
C: - SSD - No page file
D: - HDD - No page file - SATA 6.0 Gb
E: - HHD - No page file - SATA 6.0 Gb
F: - HHD - No page file - SATA 6.0 Gb

As you can see, I have the kernel running on an SSD and have the page file sitting on another physical SSD.

Would adding page files to the HHDs create additional improvements? Also, would I see optimization on the root C:\ if I turn back on the page file?

Just curious on the thoughts of the forum. Thanks for the input.

 

[emp1re]

Oh, and one last added bit. I created a partition within diskmgmt.msc in order to place the page file on it's own drive. Not that it's overkill, it's just simply a reminder for me that the cache file is installed on it's own drive letter.

 

[Ketchup]

Windows uses the amount of page file it has been programmed to use. If you have the recommended amount set, it won't matter if you set more than that amount. It won't use more, and will still be much slower than using RAM.

Moral of the story: if you are constantly using a lot of your page file, get more RAM. If you are not, having the page file on an SSD is the next best thing. If you add more page file for no reason, you will see no increase in performance.

 

[Ketchup]

Oh, and one last added bit. I created a partition within diskmgmt.msc in order to place the page file on it's own drive. Not that it's overkill, it's just simply a reminder for me that the cache file is installed on it's own drive letter.

I don't know if this will make any difference on an SSD. On a traditional hard drive, this is a bad idea, as it moves the page file out to the slower (more spread out) portion of the disk.

 

[emp1re]

Moral of the story: if you are constantly using a lot of your page file, get more RAM. If you are not, having the page file on an SSD is the next best thing. If you add more page file for no reason, you will see no increase in performance.

Wasn't sure if having the page file on a separate bus outside of root C would aid in speed.

I don't know if this will make any difference on an SSD. On a traditional hard drive, this is a bad idea, as it moves the page file out to the slower (more spread out) portion of the disk.

Question: Why would this be a bad idea? I thought that separate partitions increased speeds on a normal single HDD since it would allow access to LBA (logical block addressing) much faster since it's spread out.

Thanks for the insight. :thumbsup:

 

[Ketchup]

Question: Why would this be a bad idea? I thought that separate partitions increased speeds on a normal single HDD since it would allow access to LBA (logical block addressing) much faster since it's spread out.

It just increases the amount of times the motor has to swing the arm from one end of the drive to the other, plus the bits are packed more tightly in the inside of the drive, so there is a good bit faster read/right the toward the outside. In a traditional hard drive, "spread out" is a bad thing. Generally the spot Windows chooses for this is the best. Since it is always there, and always the same size, fragmentation also would not be a concern.

 

[ashetos]

The page file in Windows always stores old pages to disk, even if there is plenty free memory. This approach of Windows allows more memory to be used as a file-system cache. It improves overall throughput of the system if there is locality in the disk access patterns.

The tradeoff is throughput for response time. You always risk waiting to access memory that has been paged on disk even though there was always enough free memory to begin with. I always prefer response time over throughput, since i have a fast SSD and 16GiB RAM, so I explicitly disable the pagefile. That is, if you don't mind losing the ability to examine memory dumps after a BSOD. I also prefer having Windows kill one process due to out of memory errors (e.g. memory leak) instead of having the system slow down to a crawl due to thrashing of the pagefile.

 

[imagoon]

The page file in Windows always stores old pages to disk, even if there is plenty free memory. This approach of Windows allows more memory to be used as a file-system cache. It improves overall throughput of the system if there is locality in the disk access patterns.

Actually your first sentence is correct but everything else after is incorrect. The older pages get swapped but are retained in RAM until a low memory condition causes the memory to be released. This allows the machine to stay snappy unless there is a need for the RAM. Disabling the pagefile doesn't gain you anything and it removes the safety nets. The file cache only uses unallocated RAM and is released first prior to swapping to disk as well. Those together are why the system hits a wall when it runs out of RAM and actually utilizes swap. Slow RAM and lack of disk caching.

 

[ashetos]

Actually your first sentence is correct but everything else after is incorrect. The older pages get swapped but are retained in RAM until a low memory condition causes the memory to be released. This allows the machine to stay snappy unless there is a need for the RAM. Disabling the pagefile doesn't gain you anything and it removes the safety nets. The file cache only uses unallocated RAM and is released first prior to swapping to disk as well. Those together are why the system hits a wall when it runs out of RAM and actually utilizes swap. Slow RAM and lack of disk caching.

My source is Russinovich:
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

Quote:
"Some feel having no paging file results in better performance, but in general, having a paging file means Windows can write pages on the modified list (which represent pages that aren’t being accessed actively but have not been saved to disk) out to the paging file, thus making that memory available for more useful purposes (processes or file cache). So while there may be some workloads that perform better with no paging file, in general having one will mean more usable memory being available to the system (never mind that Windows won’t be able to write kernel crash dumps without a paging file sized large enough to hold them)."

I believe what I have written is accurate.

 

[Ketchup]

My source is Russinovich:
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

Quote:
"Some feel having no paging file results in better performance, but in general, having a paging file means Windows can write pages on the modified list (which represent pages that aren’t being accessed actively but have not been saved to disk) out to the paging file, thus making that memory available for more useful purposes (processes or file cache). So while there may be some workloads that perform better with no paging file, in general having one will mean more usable memory being available to the system (never mind that Windows won’t be able to write kernel crash dumps without a paging file sized large enough to hold them)."

I believe what I have written is accurate.

You wrote that having no page file is the way to go, but the article you linked says the opposite. What exactly are you trying to say?

Here is what I am saying: Windows and many Windows programs were designed to use the page file. If you don't believe me, turn it off for a while and see how long you last.

 

[ashetos]

You wrote that having no page file is the way to go, but the article you linked says the opposite. What exactly are you trying to say?

Here is what I am saying: Windows and many Windows programs were designed to use the page file. If you don't believe me, turn it off for a while and see how long you last.

I was very technical about the performance tradeoff. Russinovich says "Some feel having no paging file results in better performance, but in general...", meaning he understands it, chooses one way for average workloads, I choose another.

As far as trying turning it off and seeing how long I last, I have 5 systems that run without it for 3-4 years now, work like a charm. I do suggest 4 GiB Ram minimum however or this is simply too problematic.

 

[imagoon]

My source is Russinovich:
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

Quote:
"Some feel having no paging file results in better performance, but in general, having a paging file means Windows can write pages on the modified list (which represent pages that aren’t being accessed actively but have not been saved to disk) out to the paging file, thus making that memory available for more useful purposes (processes or file cache). So while there may be some workloads that perform better with no paging file, in general having one will mean more usable memory being available to the system (never mind that Windows won’t be able to write kernel crash dumps without a paging file sized large enough to hold them)."

I believe what I have written is accurate.

What you wrote is accurate but it is out of context (best way to put it maybe?)

The cache manager while move old pages out of the main ram but typically not for the file cache. However the cache manager does a certain minimum it keeps for NTFS operations and that number varies from (I think) 4MB to around 256MB based on system memory count. (I need to find all this as it is really buried on MSDN.) The cache manager will not put hard commits on anything above that number so the page manager will not start pushing pages to disk just to get more disk cache. All the decisions are made on "pressure" programming. If memory pressure is high due to active application utilization, then an app in the background that hasn't utilized CPU for hours may have its pages swapped out to reduce the pressure. If the active application never grows, the file cache manager may request the noncommited pages because it can release them immediately.

The take away is yes file cache can use the memory from other pages that are swapped but the cache manager itself doesn't chose this. Memory pressure had to be high enough that inactive pages were swapped by the memory manager first. IE Machine with 16GB RAM: APP A is sitting in the background doing nothing (notepad with a 2 gig text file maybe) and APP B now opens and starts requesting 14.0GB of RAM and then activates it all. File cache will begin to discard cache pages down to the minimum. Notepad will get swapped to disk. At that point file cache can grow in to the 2GB of RAM left (minus system.)

The basic idea is that notepad didn't get swapped to grow the file cache, it got swapped because memory pressure called for it to be swapped and it was the most stale application. The file cache just grew in to the newly freed RAM because it was available now.

Without a pagefile you would just get an OOM and the process manager would terminate the process.

 

[imagoon]

I was very technical about the performance tradeoff. Russinovich says "Some feel having no paging file results in better performance, but in general...", meaning he understands it, chooses one way for average workloads, I choose another.

As far as trying turning it off and seeing how long I last, I have 5 systems that run without it for 3-4 years now, work like a charm. I do suggest 4 GiB Ram minimum however or this is simply too problematic.

I would harbor a guess that you haven't gained anything by doing it and in more cases just dealt with the stability issues that can occur such as apps just shutting down when out of RAM or the blue screens when a driver can't allocate the RAM it needs. It is pretty close to just operating without a safety net. It is fine until you fall.

 

[emp1re]

It just increases the amount of times the motor has to swing the arm from one end of the drive to the other, plus the bits are packed more tightly in the inside of the drive, so there is a good bit faster read/right the toward the outside. In a traditional hard drive, "spread out" is a bad thing. Generally the spot Windows chooses for this is the best. Since it is always there, and always the same size, fragmentation also would not be a concern.

This makes total sense. Created a build for a one drive laptop and created a cache partition on it's own. I was under the impression that a distributed partition for a page file would increase the speed of accessing the swap file, however, I didn't take into account that they may then reside in the outside platters.



Thanks m8

 

[emp1re]

Currently, my machine has 16GB of RAM. My JBODs are within the initial post. I heard that the total Win7 kernel would be able to have performance gains due to segmenting an SSD drive for system cache. I can see maybe this may be a good/bad idea, or maybe arbitrary. Any ideas on how I could do a performance test?

 

[ashetos]

What you wrote is accurate but it is out of context (best way to put it maybe?)

The cache manager while move old pages out of the main ram but typically not for the file cache. However the cache manager does a certain minimum it keeps for NTFS operations and that number varies from (I think) 4MB to around 256MB based on system memory count. (I need to find all this as it is really buried on MSDN.) The cache manager will not put hard commits on anything above that number so the page manager will not start pushing pages to disk just to get more disk cache. All the decisions are made on "pressure" programming. If memory pressure is high due to active application utilization, then an app in the background that hasn't utilized CPU for hours may have its pages swapped out to reduce the pressure. If the active application never grows, the file cache manager may request the noncommited pages because it can release them immediately.

The take away is yes file cache can use the memory from other pages that are swapped but the cache manager itself doesn't chose this. Memory pressure had to be high enough that inactive pages were swapped by the memory manager first. IE Machine with 16GB RAM: APP A is sitting in the background doing nothing (notepad with a 2 gig text file maybe) and APP B now opens and starts requesting 14.0GB of RAM and then activates it all. File cache will begin to discard cache pages down to the minimum. Notepad will get swapped to disk. At that point file cache can grow in to the 2GB of RAM left (minus system.)

The basic idea is that notepad didn't get swapped to grow the file cache, it got swapped because memory pressure called for it to be swapped and it was the most stale application. The file cache just grew in to the newly freed RAM because it was available now.

Without a pagefile you would just get an OOM and the process manager would terminate the process.

You describe some interesting mechanics from the Windows (7?) kernel, as long as it actually works as you describe, not certain about that, I would appreciate a source if you find the time.

I would harbor a guess that you haven't gained anything by doing it and in more cases just dealt with the stability issues that can occur such as apps just shutting down when out of RAM or the blue screens when a driver can't allocate the RAM it needs. It is pretty close to just operating without a safety net. It is fine until you fall.

I can assure you that many laptops with hdds became cooler, more silent and snappier by just using the hdd less frequently thanks to disabled pagefile. For my SSD system, I also appreciate the fact that there are no unnecessary writes sent to the device. If you monitor the pagefile (e.g. resource monitor) you will realise it spams writes constantly.