A question for pagefile experts.

[enyceexdanny]

Hello everyone.

I have a question.

I have my os (Vista ultimate 32bit) on my 150gb raptor, and my pagefile on a seperate Raid-0 drive.

1) Although I am aware that it's better to have the paging file on a seperate drive away from the OS - does it still hold true when the seperate drive may be slower than the os drive? Raptor150gb -vs- 2 x 200gb Maxtor 7200rpm on RAID0.

So basically random access/seek times + overhead due to read/writes to/from OS (vs) maximum throughput.

2) What should the stripe width be when the raid0 volume is solely being used for the pagefile?

If the pagefile is 10 gigs, how is it read from the disk? This is what confuses me.

Pagefile is basically a large file with all the smaller files residing within, so does that mean the stripe width should be small for optimum performance?

Or since the actual pagefile.sys is large, does a larger stripe width work better.

Thanks in advance.

[Mercury_22]

If the pagefile is 10 gigs, how is it read from the disk? This is what confuses me.

How much memory do you have ?

[cluberti]

1) Although I am aware that it's better to have the paging file on a seperate drive away from the OS - does it still hold true when the seperate drive may be slower than the os drive? Raptor150gb -vs- 2 x 200gb Maxtor 7200rpm on RAID0.

Yes - if performance is your only concern, having the paging file on a separate volume (even if it's 7200RPM vs 10K) will provide better performance to the paging file than if it was on the OS disk.

2) What should the stripe width be when the raid0 volume is solely being used for the pagefile?

You have to remember that a page in memory is 4K in size - so the pagefile writes memory pages to disk, meaning all of it's "files" inside pagefile.sys are 4K in size. The problem with RAID0 and pagefile.sys is that the writes will be to a section of the paging file which could be anywhere on that RAID0 volume - you don't get any speed benefit unless you happen to write to a section of pagefile.sys that is spread across both drives, otherwise you just write to the one disk that has the section of pagefile.sys your page is going to.

You'll see benefit if you page a lot, but if you have a decent amount of RAM you probably won't see any benefits of a RAID0 vs a RAID1 for pagefile.sys. This is one of the files that really doesn't benefit from fast RAID configurations like RAID0, 0+1, or 10, but will suffer in a tolerant array type like RAID5 (reads are fast, writes are slower). That is why it is usually recommended to store the OS and pagefile.sys on RAID1 arrays - if you must use a RAID, using a RAID1 provides some fault tolerance without the write penalty, and isn't as expensive in disk space as a RAID10 or 0+1 - and you won't lose it entirely if you lose one of the disks in the array like you would if you use a RAID0.

[enyceexdanny]

Wow, thanks for the detailed answer cluberti.

Well, I have 4 gigs of ram.

I never knew that all files in the pagefile were only 4K each! That's news to me.

I did hear that it runs in 4k streams.. But didn't quite understand that till now.

That's a bummer that RAID0 has no effect on paging.

And since the files are 4k in size, and i believe the lowest stripe width is 4k (?) - it makes no difference huh.

So if, for example - the stripe width can be 2k, then it should benefit?

Thanks again for the informative response

[Mercury_22]

I have the same amount of ram 4GB and i'm not using pagefile !

I've tested my system (2x74 RAPTOR RAID 0) with pagefile and without pagefile and i discover that i'm better without pagefile

So i recommend you that if the amount of memory used by the applications usually open at the same time on your system it's lower than 3GB, to forget about pagefile

At least try and convince yourself !

[cluberti]

I never knew that all files in the pagefile were only 4K each! That's news to me.

I did hear that it runs in 4k streams.. But didn't quite understand that till now.

Yes, a "page" is 4K, so all "pages" in memory written to the paging file are thus 4K in size, always.

That's a bummer that RAID0 has no effect on paging.

I wouldn't say it would have no effect, but it would be so minimal as to not even bother with the hassle and worry of losing a paging file if one of the 2 disks goes bad. If you're going to do RAID, a RAID1 would be much better for the paging file.

So if, for example - the stripe width can be 2k, then it should benefit?

Yes, that might speed things up a bit as your probability of hitting a location in the page file that would split the I/O would be greater. I'm not sure I'd recommend it, but the theory is sound.

I've tested my system (2x74 RAPTOR RAID 0) with pagefile and without pagefile and i discover that i'm better without pagefile

That's because you've changed your commit limit, and forced the NT memory manager to be biased towards committing to RAM so that it will only be able to commit VA pages from applications into RAM. The memory manager can only commit pages to a backing store (RAM or paging file), and if you only have RAM (or RAM and a very small paging file), all or most of your pages committed will have to be in RAM because they can be nowhere else. It'd be a problem if you tried to commit more VA than you have RAM in the box, but that's the only drawback to not having a paging file performance-wise. You can't dump the box or get data from a crash without a paging file, but that has nothing to do with performance.

[dkhandel]

Hi Dude,

Microsoft says "When thinking about the size of the paging file, the sum of all the files that make up the paging file is the only value you need to keep in mind.". I think point 2 answer to your questions. However, alternatively, this articles http://support.microsoft.com/kb/314834/en-us (XP version)

The following two guidelines should be met when optimizing the paging file:

1. In general, you should set the size of the paging file to the same size as your system RAM plus 12 MB. There is a minimum size requirement of 22 MB for the operating system. If system RAM plus 12 MB is less than 22 MB, increase the size of the paging file until your system RAM plus paging file is at least 22 MB. NOTE: 22 MB is just what the operating system requires for itself. For reasonable application performance, a 40 MB total is recommended.

These sizes are recommended because Windows NT requires "backing storage" for everything it keeps in RAM. If Windows NT requires more space in RAM, it must be able to swap out code and data to either the paging file or the original executable file. If Windows NT cannot do this, out of memory errors will be generated.

If you set your paging file to system RAM plus 12 MB and you still get low memory warnings, try increasing the size of the paging file. If you need more disk space and you are not getting memory warnings or memory-related problems, you can try to decrease the size of the paging file.

Also, if you have enough surplus RAM to support the operating system and application memory requirements, the need for a large paging file is lessened. If you have, for example, 64 MB of RAM, you may be able to safely reduce your paging file to a very small size.

2. If you have multiple hard disks, splitting up the paging file is a good idea, as it will speed up the access time. If you have two hard disks, and you split the paging file, both hard disks can be accessing information simultaneously, greatly increasing the throughput. However, if you have two hard disks, and one hard disk is faster than the other, it may be more effective to store the paging file on only the faster hard disk. Some experimentation may be necessary to arrive at the best configuration for your system.

Note: There is no point in splitting up the paging file between multiple partitions as it does not increase the ability of the hard disk to access the paging file. This may be a good idea, however, if your logical drives aren't large enough for the entire paging file.

Best wishes,

Dilip.

[Mercury_22]

I've tested my system (2x74 RAPTOR RAID 0) with pagefile and without pagefile and i discover that i'm better without pagefile

That's because you've changed your commit limit, and forced the NT memory manager to be biased towards committing to RAM so that it will only be able to commit VA pages from applications into RAM. The memory manager can only commit pages to a backing store (RAM or paging file), and if you only have RAM (or RAM and a very small paging file), all or most of your pages committed will have to be in RAM because they can be nowhere else. It'd be a problem if you tried to commit more VA than you have RAM in the box, but that's the only drawback to not having a paging file performance-wise. You can't dump the box or get data from a crash without a paging file, but that has nothing to do with performance.

So what's your recommendation in this case for the best performance & stability ? (with or without pagefile) And why? B)

Edited November 9, 2007 by Mercury_22

[cluberti]

So what's your recommendation in this case for the best performance & stability ? (with or without pagefile) And why? B)

Well, I always recommend a paging file, but the size depends on what you need. I always recommend it because there are some memory operations in kernel that really do require that you have a pagefile as a backing store in case some of the executive and paged pool needs to be paged out. However, if you don't plan on gathering data from a crash if it was to occur, I recommend a pagefile that is ~600MB in size for an x86 system with 4GB of RAM - that's large enough to handle the entirety of kernel paged pool being paged out, but still modifies your commit limit in such a way that almost all pages will be in RAM at any time.

However, everyone's system usage is different, so monitoring your machine with perfmon (specifically the Process > Working Set counter for the _Total instance) to see how much VA across all running processes is actually in RAM. If you notice that the _Total counter gets up near 4GB, you need a pagefile, because you have the very real possibility your system will try to commit more VA to RAM than you have RAM to back it. When that happens, you'll likely get very odd behavior in the app, probably some app crashes, and the kernel won't like it too much either and Windows will possibly become somewhat unstable for a time as well. If you find that your _Total instance for the Working Set counter in Process stays under 3.5GB, you should be just fine with a 600MB or so pagefile.

[Mercury_22]

What about "Automatically manage paging" option from VISTA (x64) ?

[Taliseian]

IIRC, when you let the system automatically manage the page file, it will grow or shrink the paging file as necessary.

From my understanding of pagefile mechanics, that can cause the pagefile to be fragmented on systems with long uptimes and ones that run many applications. Each time there is a need the pagefile grows, and when there is no need it shinks, regardless of other file usage.

The best pagefile setup is a large, fixed pagefile on a fast drive that doesn't have the OS on it. On my system I usually put the pagefile on the secondary controller, primary drive, and its fixed at around 3gb. I put it there so that any paging calls are made on the secondary contoller isolated from any OS or application calls so that I can take advantage of "hardware multitasking" - the OS/Apps use the primary contoller to its fullest extent while any pagefile calls are on the secondary.

T

[Mercury_22]

IIRC, when you let the system automatically manage the page file, it will grow or shrink the paging file as necessary.

Are you sure about shrinking ? I've watch my page file and i never seen it shrinking

[cluberti]

Are you sure about shrinking ? I've watch my page file and i never seen it shrinking

If it's set to auto manage, it should shrink it on reboot back to a smaller size based on the amount of RAM in the machine and usage patterns. Again, unless you think you need it, configuring a min and max size manually to between 600 - 800MB on Vista x86 should be fine.