performance increase by having page file on seperate hard drive

[EnderW]

I'm thinking of adding a drive just to put my page file on.
Anyone have info on if this increases performance and by how much/what area?

 

[Michael Daly]

Anyone have info on if this increases performance and by how much/what area?

That will depend on how much RAM you have, what applications you use etc. If you've got the extra drive, the easiest thing to do is test and see.

 

[Ockie]

Why don't you add more ram and disable page filing?

 

[lifeinchains]

Why don't you add more ram and disable page filing?

I thought thats been debunked as not really helping anything?

 

[unhappy_mage]

I thought thats been debunked as not really helping anything?

Adding more ram has never hurt*. Disabling paging is generally not a good idea; see How to: Size your windows XP page file. I'd tend to leave the pagefile enabled, to allow for more system stability in times of memory demand.

*Except where it makes the memory downclock. Opterons, I'm looking at you.

 

[Ockie]

Adding more ram has never hurt*. Disabling paging is generally not a good idea; see How to: Size your windows XP page file. I'd tend to leave the pagefile enabled, to allow for more system stability in times of memory demand.

*Except where it makes the memory downclock. Opterons, I'm looking at you.

I don't see how having a sligh increase in performance is hurting. If you don't get BSOD's then you have nothing to worry about.

Besides, if you have enough memory then you have no problems with disabling it.


You forget to include the most important aspect, less power consumption and also less drive wear + heat by disabling pagefiling and instead relying on more memory.

 

[Ockie]

I thought thats been debunked as not really helping anything?

It helps a lot. Perhaps not in your benchmarking runs as they have a fixed memory usage limit and perhaps not on programs that wont exceed your pagefile system anyways.


However, toss vista ultimate on 512mb memory with file paging, then try disabling pagefile and tossing in 2 gigs of ram... tell me if it's going to make a diffrence or not.

Rather than tossing in more drives into your machine, why not just put in more memory, less wear, less heat, less power... leave the drive to do what it does best.

 

[unhappy_mage]

I don't see how having a sligh increase in performance is hurting. If you don't get BSOD's then you have nothing to worry about.

Let me preface this by saying this is hypothetical. I haven't written any operating systems, and definitely not the one you're using.

What if having swap on allowed the OS to push things it's not likely to use onto disk, in order to have more memory free for faster allocation when it comes time to allocate more to user programs? malloc() isn't free; perhaps having fewer pages in memory used could let it run faster and thus get your task done faster without system services interfering with it.

However, toss vista ultimate on 512mb memory with file paging, then try disabling pagefile and tossing in 2 gigs of ram... tell me if it's going to make a diffrence or not.

Well, duh. How about 2 gigs/no PF versus 2 gigs/standard PF? I don't think 512/PF versus 2 gigs/no PF is a very relevant test.

 

[EnderW]

Why don't you add more ram and disable page filing?

that doesn't work
there is a somewhat technical article I remember reading that explains why, I'll see if I can find it

edit: can't remember if this is it, but it explains the issue well
my question about moving the pagefile is also addressed, although it's still unclear how much performance is increased
http://mywebpages.comcast.net/SupportCD/XPMyths.html#Optimization

 

[oplin]

2gigs doesn't seem like enough memory to disable the page file, 4gigs and you'd probably be in the clear. As a developer i can have more than 2gigs in use and have a huge page file at times. When gaming some games will eat up more than 2 gigs.

I personally like having the page file split up or off of the windows drive it seems like loading is alot faster and genereally all around smoother experiance. I have 2 gigs of ram and 6 hard drives, usually split it up on 2 or 3 hard drives that are used for storing movies or backups. I usually make them 512 megs and have a fixed size sothey don't change. 2gigs and 2gig page file.

 

[Michael Daly]

2gigs doesn't seem like enough memory to disable the page file, 4gigs and you'd probably be in the clear.

If you use 32 bit Windows, you won't get the full 4GB anyway.

If you set the pagefile to zero on all drives, Windows will still create a pagefile on the boot drive. It has to have a pagefile for some reason - to handle a failed boot or something like that. Once it's there, it will use it.

 

[Eickst]

Some programs expect to see a pagefile. Disabling it actually breaks some of them.

 

[uOpt]

You never want to disable the pagefile. It will never make things faster. If you really had so much RAM that it isn't needed at all then it won't be used even if present.

But if you lack it then you force the OS to keep useless anonymous and copy-on-write pages in main memory long ater they are proven useless, and that memory goes right off what you can use for readonly mappings (read: you program's code) and filesystem buffer cache.

Paging space should always be on all drives, on the plain drives, not raided (unless you actually use hotswap in which case you put in into the redundant raid layers but not into the raid-0 layers), at least for single-person machines (even with heavy multitasking). At the time of a pageout the system is stalled anyway, and you want to get over the stall as soon as possible.

The theory to "keep paging space away from data space" is nonsense because the system is stalled anyway. While a heavy pageout is in progress there will be no disk activity in your data areas.

Keep in mind that normal disk write is asynchronous but pageout is not. Neither is pagein or reading.

 

[Ockie]

Well I guess the OP has his answer.

 

[Keetha]

In windows XP you can't disable the page file. Even if you select "no page file", it still uses one. And even with 2GB or more RAM and running no programs, your page file is still used.

http://support.microsoft.com/default.aspx?scid=kb;en-us;555223

 

[Michael Daly]

The theory to "keep paging space away from data space" is nonsense because the system is stalled anyway. While a heavy pageout is in progress there will be no disk activity in your data areas.

This contradicts MS's own recommendations.

BTW - what exactly do you mean by "stalled"?

 

[unhappy_mage]

BTW - what exactly do you mean by "stalled"?

If the OS gets into a state where the only thing it's doing is waiting for a particular page from disk, it won't do anything else. With enough memory allocated, that could happen.

 

[uOpt]

This contradicts MS's own recommendations.

BTW - what exactly do you mean by "stalled"?

When you run so low on memory that the OS initiated a large pageout then the application that requested more memory in first place is stalled - it won't do anything because it waits for the OS to give it the memory requested.

In particular, there will be no or almost no disk activity other than the pageout. Again, keep in mind that normal disk write is asynchronous but pageout is not.

 

[Michael Daly]

When you run so low on memory that the OS initiated a large pageout then the application that requested more memory in first place is stalled - it won't do anything because it waits for the OS to give it the memory requested.

In particular, there will be no or almost no disk activity other than the pageout. Again, keep in mind that normal disk write is asynchronous but pageout is not.

But couldn't another process get cycles and initiate disk activity?

 

[uOpt]

But couldn't another process get cycles and initiate disk activity?

That's unlikely on single user machines.

But even if so, the disk I/O of the new consumer will most likely happen after the pageout or pagein finished.

Let's consider the different cases, dual writers first.

If the second process writes, and there is a large pageout already ongoing from the first process requesting too much memory, then the second processes' written data will go into the filesystem buffer cache. The pageout activity will never go into the filesystem buffer cache. Of course it will go through it, but not for longer than for reordering for better efficiency, in effect a pageout is pretty much synchronous disk activity. The result is that the data written from the second process does not trigger actual disk I/O that would interfere with the pageout, aka there would be no fighting for the disk.

%%

Dual-read:

If you have a pagein as a result of suddenly touching large amounts of data that had been paged out (such as using a long-sleeping process) and you have a second process suddenly starting to read, then the situation is more complex and not easily predictable. Strictly speaking, there is no such thing as touching large amounts of paged out memory. You can only touch one page at a time, then wait until the program can continue after the pagein. Of course there will be some readahead done by the OS.

But that dual read situation is also subject to the difference between readonly pages on one hand and anonymous and copy-on-write pages. In particular, in almost all programming language runtime models the actual code is readonly mapped.

That means that the code is never swapped out. Readonly mapped pages are just dropped from memory and when later touched are read back from the original location - which is not in swapspace, it is where you install programs, aka your data space.

As a result it is of no use to separate data from pageout space on different harddrives to improve pagein activity as much or most of the pagein activity will happen on the data disk, not the pageout disk.

You have to take into account that the operating system knows that readonly pages are cheaper to page, because there is only pagein and there is never pageout. As a result, when you have a program with -say- 200 MB of readonly pages and 200 MB of read/write pages then you will find that a significant larger portion of the read/write pages will still be resident and that many more readonly pages have been dropped than read/write pages have been swapped out. This further increases the amount of data paged in from data space, not paging space.

Clearly, this pattern is overall worked up faster with paging space in as many drives as possible than by trying to separate data and paging space, even in the presence of a second data reader.

%%

I've got to get lunch now. If there's interest I can post about situations where a new reader interferes with a large pageout operation already in progress. That is probably the situation where separation comes closest to a benefit and you would have to do actual benchmarking to find out what's better. But in a mix with the other patterns it's not going to be better from a total system standpoint.

 

[Michael Daly]

Thanks for your explanations.

Of course there will be some readahead done by the OS.

Is this basically optimization - i.e. if the current page is needed, then the next one will likely be needed too, so load it now, not later?

Mike

 

[Caffeinated]

To reiterate, I've run Windows XP both with a page file and without a page file, and it runs better with one. When I am doing a defrag using the Windows utility, i boot into safe mode after turning off the page file (I always turn off restore, it isn't useful for me) so that everything gets defragged. I left it off to see if I would get a performance increase, and ran it like that for about a week. I had 2 GBs of RAM. It wasn't awful, but it wasn't great either. I rarely boot, so it was sucking after a few days. I set a static page file, rebooted and all was better.

I set static page files that are 1.75X the size of system RAM for a system with 2GBs.

Also, to clear up any confusion, Windows XP (or any 32-bit Microsoft OS, for that matter) cannot address much more than 2GBs unless you use the /3GB switch, which forces the OS out of resident memory and into paging so that applications can address the 3 GBs, rather than ~2.25GBs which is typically where it bottoms out. As you can imagine, this is not optimal for desktop usage and performance, and only truly benefits a server application. A server isn't used locally, so it is beneficial. Don't bring Linux or OS X into this , because it *Nix based OS's have a different memory usage model than Windows, though 32-bit flavors of those ALSO have a 4GB total addressable limit, and again, they usually top out somewhere around ~3.25 on their very best days.

Summary: Page file good. More than 2GBs of RAM on 32-bit XP, not useful. /3GB switch on XP, bad. /3GB switch and no page file, very bad.

 

[lawrence131]

Paging space should always be on all drives.

I agree with most of the points but if you have 4+ drives why keep a page file on your OS/Apps drive? Unless the OS knows to avoid using that pagefile whenever the OS/Apps drive is in use, it could slow down performance by choosing that pagefile instead of the file on the other 3 drives. I don't see how 4 swap files is better than 3 or even 2 when it raises the risk of being accessed when data on the same drive is being accessed.

 

[uOpt]

Is this basically optimization - i.e. if the current page is needed, then the next one will likely be needed too, so load it now, not later?

Yes. In particular if it is a code page the OS can assume that pretty soon the next page(s) will be requested, too. And even if not, just getting 4 KB (a page on x86 and x86_64) is pretty wasteful and getting 16 KB might be pretty much equally fast. Then you have the tradeoff of memory used, so you might want to tune this based on your memory stress.

There is no guarantee that this actually happens, OSes can do whatever they want and for Windoze we don't have source to look. Linux, e.g. used only to do readahead on normal reads (through files) and not on mappings. That looks good in benchmarks but is pretty stupid in practice. Now they have a (tuneable) readahead for both.

 

[uOpt]

To reiterate, I've run Windows XP both with a page file and without a page file, and it runs better with one. When I am doing a defrag using the Windows utility, i boot into safe mode after turning off the page file (I always turn off restore, it isn't useful for me) so that everything gets defragged. I left it off to see if I would get a performance increase, and ran it like that for about a week. I had 2 GBs of RAM. It wasn't awful, but it wasn't great either. I rarely boot, so it was sucking after a few days. I set a static page file, rebooted and all was better.

This is to be expected. As I explained earlier, by not using a pagefile you force Windows to keep all kinds of junk in RAM and has no choice than to drop more pages that you actually use frequently, and it uses less filesystem buffer cache which is also a big deal.

Also, to clear up any confusion, Windows XP (or any 32-bit Microsoft OS, for that matter) cannot address much more than 2GBs unless you use the /3GB switch, which forces the OS out of resident memory and into paging so that applications can address the 3 GBs, rather than ~2.25GBs which is typically where it bottoms out. As you can imagine, this is not optimal for desktop usage and performance, and only truly benefits a server application. A server isn't used locally, so it is beneficial. Don't bring Linux or OS X into this , because it *Nix based OS's have a different memory usage model than Windows, though 32-bit flavors of those ALSO have a 4GB total addressable limit, and again, they usually top out somewhere around ~3.25 on their very best days.

Summary: Page file good. More than 2GBs of RAM on 32-bit XP, not useful. /3GB switch on XP, bad. /3GB switch and no page file, very bad.

That is a misunderstanding. The 2 or 3 GB limit is a virtual memory limit for the userlevel processes. It has nothing to do with how much physical memory the machine has for for what it is used.

The memory model is the same for Windows and Unix derivates, most use 3 GB virtual for userlevel processes and the upper 1 GB for the kernel. Linux has the 4GB/4GB VM split patch (now defunct) that allows you to go close to 4 GB virtual memory. Windows has the switch to switch between 2 and 3 GB.

All these 32 bit OSes can use much more than 4 GB (physical) RAM when they have PAE, but can only ive it out 3 GB virtual to each userlevel process. However, a 3 GB userlevel process doing some kind of own swapping scheme (not OS paging) can easily use up more than these 3 GB memory via the filesystem cache.

Windows XP removed (or heavily disabled) PAE in SP2, but that's an irrelevant detail.

 

[uOpt]

I agree with most of the points but if you have 4+ drives why keep a page file on your OS/Apps drive?

Because the system is stalled anyway, so your OS/app drive will not see other disk activity.

By adding the disk to the pool of disks the kernel can page to you speed up the process of paging out, thus making the stall shorter.

Unless the OS knows to avoid using that pagefile whenever the OS/Apps drive is in use, it could slow down performance by choosing that pagefile instead of the file on the other 3 drives. I don't see how 4 swap files is better than 3 or even 2 when it raises the risk of being accessed when data on the same drive is being accessed.

You can give it a lower priority if you wish but as I said, your base assumption is wrong in most cases because that non-paging activity is not there. It stopped because the system is stalled in most cases (I gave evaluations of special cases earlier).

And 4 drives versus 3 can make a huge difference. It is not unrealistic to expect the stall to be over in 20-30% less time.

Or in other words: if you stall because of a large pageout operation then you need to commit ALL resources into resolving the stall.

 

[Michael Daly]

By adding the disk to the pool of disks the kernel can page to you speed up the process of paging out, thus making the stall shorter.

Are you saying that Windows will write to more than one drive for a single paging operation? Or is it just that it will write to the least used drive?

 

[uOpt]

Are you saying that Windows will write to more than one drive for a single paging operation? Or is it just that it will write to the least used drive?

Yes, that's the whole point.

Let's say the OS determines it needs 4 MB more RAM because of some request via memory allocation or file transfer. 4 MB are 1024 pages on x86 and x86_64.

When it moves out these 1024 pages and you have four paging areas, then it will move 256 pages to each paging area.

Very obviously, you can write 256 each to 4 drives much faster than you can write 1024 blocks to one drive.

That is also the reason why paging space shouldn't live in RAID-0, because then you will prevent the OS from optimizing it, pushing the same amount of each drive and you will end up waiting for the drive that ended up with more blocks than the others.

This is not any different on Windows or Unix, BTW.