Page file management for best performance

tempoct

Senior member
May 1, 2006
246
0
0
Which one has best real world performance. Says all on a single RAID 0 volume.
1. OS and page file on same partition
2. Page file is in different partition than OS.
3. Page file is in different and dedicated partition (sized just little bigger than needed size)

General rules (AFAIK) is page file should be set with static size (for the recommended size, which usually 1.5 x Physical Memory size).

Wonder which one has best performance in real world. If the performance doesn't differ much, choice 1 is the best for simplicity.

What do you think? This is for XP 32 and Vista 64. OS shouldn't be much different though.
 

xtknight

Elite Member
Oct 15, 2004
12,974
0
71
What partition it's on makes little, if any, difference, but you could see performance gains by putting the page file on a faster HD.

2. Page file is in different partition than OS.
3. Page file is in different and dedicated partition (sized just little bigger than needed size)

What is the difference between those two options? The second one is the same thing just bigger?
 

tempoct

Senior member
May 1, 2006
246
0
0
The third one has nothing else in there but page file. The 2nd one might contains other stuff, maybe Program Files folder, regular document files, etc.

Originally posted by: xtknight
What partition it's on makes little, if any, difference, but you could see performance gains by putting the page file on a faster HD.

2. Page file is in different partition than OS.
3. Page file is in different and dedicated partition (sized just little bigger than needed size)

What is the difference between those two options? The second one is the same thing just bigger?

 

xtknight

Elite Member
Oct 15, 2004
12,974
0
71
Oh, alright. Well, the fact that other files are on the partition is probably also irrelevant, though I'm not sure how fragmentation fits into this.
 

bsobel

Moderator Emeritus<br>Elite Member
Dec 9, 2001
13,346
0
0
Originally posted by: tempoct
Which one has best real world performance. Says all on a single RAID 0 volume.
1. OS and page file on same partition
2. Page file is in different partition than OS.
3. Page file is in different and dedicated partition (sized just little bigger than needed size)

General rules (AFAIK) is page file should be set with static size (for the recommended size, which usually 1.5 x Physical Memory size).

Wonder which one has best performance in real world. If the performance doesn't differ much, choice 1 is the best for simplicity.

What do you think? This is for XP 32 and Vista 64. OS shouldn't be much different though.

If you don't have a seperate dedicated drive, you want it on the most accessed partition so seek times don't become exsesive.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
General rules (AFAIK) is page file should be set with static size (for the recommended size, which usually 1.5 x Physical Memory size).

People keep saying that but don't back it up with any facts as to why it's a good idea. And no an expanding and shrinking pagefile isn't a reason because once you're at the point that the pagefile will be expanded you're paging enough that you'll never notice the difference and the pagefile only shrinks on reboots.

Wonder which one has best performance in real world. If the performance doesn't differ much, choice 1 is the best for simplicity.

Exactly, unless you're pushing your machine too hard you'll never notice the pagefile is even there. And if you are hitting the pagefile then your little optimizations won't matter much either because disk access in general will be killing the performance and in that case the only real solution is to get more memory.
 

tempoct

Senior member
May 1, 2006
246
0
0
Originally posted by: Nothinman
General rules (AFAIK) is page file should be set with static size (for the recommended size, which usually 1.5 x Physical Memory size).

People keep saying that but don't back it up with any facts as to why it's a good idea. And no an expanding and shrinking pagefile isn't a reason because once you're at the point that the pagefile will be expanded you're paging enough that you'll never notice the difference and the pagefile only shrinks on reboots.

Well, I kinda know the reason why fixed page file size might help. If the resizable page file allow. Windows will actually resize them (smaller first and grow later). This introduce chance of getting the page file fragmented. Fixed page file size when you first install Windows will guarantee no fragmentation. You can run defragmenter and see the report to check if page file is fragmented or not. If so, you can remove it (Set to no page file), restart, defragmented and re-create the new page file which will be single fragment.


Wonder which one has best performance in real world. If the performance doesn't differ much, choice 1 is the best for simplicity.

Exactly, unless you're pushing your machine too hard you'll never notice the pagefile is even there. And if you are hitting the pagefile then your little optimizations won't matter much either because disk access in general will be killing the performance and in that case the only real solution is to get more memory.

Agree.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
This introduce chance of getting the page file fragmented.

Which is irrelevant, data stored in the pagefile is put there in pretty much random order so the pagefile isn't accessed in large contiguous chunks.

You can run defragmenter and see the report to check if page file is fragmented or not. If so, you can remove it (Set to no page file), restart, defragmented and re-create the new page file which will be single fragment.

So? The defragmenter tells you losts of things that are pointless.
 

kY

Senior member
Feb 21, 2003
769
0
76
If you have multiple hard drives on independent controllers, then it does improve page file performance to spread the page file across multiple hard drives.
 
Feb 9, 2005
41
0
0
You do not need to create a page file that is 1.5 times the size of the RAM for systems with large amounts of RAM because seriously, that defeats the purpose of having the RAM. Accessing and writing to the page file drastically reduces the performance of the system. In the event that you are using the page file often, which drive the page file is on is not going to make nearly as much of a difference as installing more RAM will. If installing more RAM is not an option, placing the page file on a separate channel and hard drive from the OS will have the greatest performance. Also, the page file should be set to static because resizing it does increase the chance of fragmentation and fragmentation does decrease the performance of the page file. Note, the page file can still get fragmented even if the size is static, it's just less likely to. The reason this decreases the performance is that when you have to expand the size of the page file, there is generally heavy page file usage, and if there is also fragmentation, the hard drive will be reading from all over the platters to access the page file. If it's in one spot, it can access the data more quickly.

To answer the original question, there will not be a performance difference unless the page file is on both a different channel and a different hard drive. Having a different partition for the page file on the same hard drive wouldn't be much different than making the size of it static.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
You do not need to create a page file that is 1.5 times the size of the RAM for systems with large amounts of RAM because seriously, that defeats the purpose of having the RAM.

Unless you're doing kernel level debugging and need a full memory dump.

If installing more RAM is not an option, placing the page file on a separate channel and hard drive from the OS will have the greatest performance.

Not if the apps or games of which you're trying to increase the performance are installed on that drive.

Also, the page file should be set to static because resizing it does increase the chance of fragmentation and fragmentation does decrease the performance of the page file

Where is your proof of that? The pagefile is accessed almost completely at random, it's data is already fragmented so whether the file itself is contiguous or not has virtually no effect.

The reason this decreases the performance is that when you have to expand the size of the page file, there is generally heavy page file usage, and if there is also fragmentation, the hard drive will be reading from all over the platters to access the page file. If it's in one spot, it can access the data more quickly.

Not true, if you're that low on memory then you'll be paging from all over the disk anyway no matter where the pagefile is located.
 
Feb 9, 2005
41
0
0
My proof? It's common sense. If you have to move farther across a disk to get to data that you need a lot, it will take longer than if you are moving across a smaller chunk. If your page file is not fragmented, that means it is in one chunk.

http://support.microsoft.com/kb/555223#csDisclaimer
which links to here for more information:
http://members.shaw.ca/bsanders/Windows...ralWeb/RAMVirtualMemoryPageFileEtc.htm

And I forgot to mention in the first post that the best way to determine the page file size that you need is by monitoring your page file usage during various activities. If you commonly access it, you should probably get more RAM, if you only access it while doing a few things where performance isn't overly critical, you should set the page file to have a safe margin over what those few things need.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
My proof? It's common sense. If you have to move farther across a disk to get to data that you need a lot, it will take longer than if you are moving across a smaller chunk. If your page file is not fragmented, that means it is in one chunk.

Obviously seek times matter, but when you're low on memory Windows will be paging from more than just the pagefile so the pagefile's fragmentation will have little to no effect. And the data in the pagefile will almost always be in more than one logical chunk since data stored in the pagefile isn't sorted in any fashion.
 

bendixG15

Diamond Member
Mar 9, 2001
3,483
0
0
MS says.......

The optimal solution is to create one paging file that is stored on the boot partition, and then create one paging file on another partition that is less frequently accessed on a different physical hard disk if a different physical hard disk is available. Additionally, it is optimal to create the second paging file so that it exists on its own partition, with no data or operating-system-specific files

Read the rest here......
http://support.microsoft.com/kb/314482/en-us
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
Additionally, it is optimal to create the second paging file so that it exists on its own partition, with no data or operating-system-specific files

Which goes against common knowledge because that'll just cause more full seeks because whenever you do need to access the pagefile the hard disk will have to seek all the way out of the current filesystem to that lone partition.
 
Feb 9, 2005
41
0
0
Also from the same article:

When you put a paging file on its own partition, the paging file does not become fragmented, and this counts as another definite advantage. If a paging file resides on a partition that contains other data, it may experience fragmentation as it expands to satisfy the extra virtual memory that is required. An unfragmented paging file leads to faster virtual memory access and to a greater chance of a dump-file capture that is free of significant errors.

It doesn't just mean in another partition, it means in another partition on another physical disk if possible.
 
Feb 9, 2005
41
0
0
Yeah, and Windows takes that into account. That's why it is best to have to page files, so that Windows can decide which one to use to have the least of a performance hit.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
The dumpfile portion I can't contend because I have no idea how that works, the fact that they do it at all is scary because once the kernel crashes I wouldn't trust it to properly write any data to disk.

But the pagefile fragmentation makes no sense, just think about it, when the system is low on memory it's going to be looking to free memory from wherever possible which includes binaries and shared libraries that haven't been used in a while. So the minute you do something that requires one of those files it'll have to page them back in which aren't in the pagefile so it'll be seeking back to wherever they are in the filesystem. Add onto that images, temp files, registry data, etc that have a static backing store in the filesystem and you realize that the pagefile only plays a small part in the performance problems created by low memory. The pagefile is only used for things without some other backing store so in mosts cases that's limited to private data that's been modified i.e. that image you have opened in photoshop, but the photoshop executable will never be put into the pagefile because it can be read back from the filesystem if necessary. And on top of all that the readahead in Windows maxes out at 64K IIRC so even if the data in the pagefile is contiguous it'll still have to be paged back in via multiple requests. So while I don't contend that it can make a difference, I don't think it'll make an appreciable difference and any time spent tweaking it is time wasted. Infact the time I wasted typing this out is probably more than OP has spent using his pagefile since he built his machine.

So go ahead and tweak it if you'd like but it's nearly analogous to changing the rubber on your shoes in the hopes that it'll make you an Oplympic-class runner.
 

bendixG15

Diamond Member
Mar 9, 2001
3,483
0
0
My Pappy used to say.......

A little knowledge is a dangerous thing

(I often wondered if he was right)
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
My Pappy used to say.......

A little knowledge is a dangerous thing

(I often wondered if he was right)

There's no question that any amount of knowledge can be dangerous, but a little bit is usually worse than a lot because you won't understand all of the repercussions of whatever you're tinkering with.
 

nweaver

Diamond Member
Jan 21, 2001
6,813
1
0
Originally posted by: Nothinman
This introduce chance of getting the page file fragmented.

Which is irrelevant, data stored in the pagefile is put there in pretty much random order so the pagefile isn't accessed in large contiguous chunks.

You can run defragmenter and see the report to check if page file is fragmented or not. If so, you can remove it (Set to no page file), restart, defragmented and re-create the new page file which will be single fragment.

So? The defragmenter tells you losts of things that are pointless.

my (test enviro) exchange server crashed (dismounted the mail store) due to a heavily fragemented page file....
 

kobymu

Senior member
Mar 21, 2005
576
0
0
Which goes against common knowledge because that'll just cause more full seeks because whenever you do need to access the pagefile the hard disk will have to seek all the way out of the current filesystem to that lone partition.
I understand this specific optimization as: if you work load very greatly, giving the page file its own partition will reduce its *multiple* seek time (read: fragmented page file). by containing it a into separate partition the seeks should be faster becuase the multiple seeks dont have to go through large blocks of user data.


 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
my (test enviro) exchange server crashed (dismounted the mail store) due to a heavily fragemented page file....

Which makes absolutely zero sense and since I can't see the source for either of them I can't even guess as to why that would happen. But I believe it's safe to say that your experience is an extreme corner-case and this thread was about workstation use.

I understand this specific optimization as: if you work load very greatly, giving the page file its own partition will reduce its *multiple* seek time (read: fragmented page file). by containing it a into separate partition the seeks should be faster becuase the multiple seeks dont have to go through large blocks of user data.

But you will almost certainly be paging from other files too so you will be seeking to those other partitions unless the pagefile is on it's own dedicated physical disk.
 

nweaver

Diamond Member
Jan 21, 2001
6,813
1
0
Originally posted by: Nothinman
my (test enviro) exchange server crashed (dismounted the mail store) due to a heavily fragemented page file....

Which makes absolutely zero sense and since I can't see the source for either of them I can't even guess as to why that would happen. But I believe it's safe to say that your experience is an extreme corner-case and this thread was about workstation use.

I understand this specific optimization as: if you work load very greatly, giving the page file its own partition will reduce its *multiple* seek time (read: fragmented page file). by containing it a into separate partition the seeks should be faster becuase the multiple seeks dont have to go through large blocks of user data.

But you will almost certainly be paging from other files too so you will be seeking to those other partitions unless the pagefile is on it's own dedicated physical disk.

except....

I couldn't understand why, but the other guy working, who had years and years of exchange experience looked at it and said "check your defrag, betcha you got a fragmented page file" and he was right. Defrag, reboot (previous reboots had not helped) and all was good.
 

kobymu

Senior member
Mar 21, 2005
576
0
0
But you will almost certainly be paging from other files too so you will be seeking to those other partitions unless the pagefile is on it's own dedicated physical disk.
The idea is to contain the page file to its own dedicated partitions assumes that the page file is on that partition only and I'm pretty sure that was original suggestion, spanning the page file to multiple partition on the same disk would of course be completely redundant.