• A Great friend to the HardForum with a great kid that he is trying to get a scholorship to continue his schooling. Please give hime a vote! Only 24 hours left! Thanks.
    If you have an VOTE FOR KEENAN!

Where to put pagefile?

BeavermanA

2[H]4U
2FA
Joined
Apr 27, 2006
Messages
3,320
I have 2x Raptor's in RAID 0 and a 320GB 7200.10 SATA2 Seagate hdd. The OS is on the raid; is it still better to set the pagefile on the single hdd even though it is much slower?
 
If it was me i would put it on the slower drive. Or at least split it between the 2. Aparently you can't get a good dump with the pagefile being on a different drive but that shouldn't matter unless you're running a server or something mission critical. I always like to seperate my page file and os, but it'll be nice to hear some other peoples opinions as mine is based just on what i feel is faster and logically seems the best way to do it.
 
It doesn't really matter. The pagefile works just like any other file, it gets written to AND read from. When it's being written it's usually done in the background where windows removes idle ram memory and puts it into the page for future use. When it's being read it's usually because you've run out of RAM... but when does that happen? Well it can happen a couple different ways. You can be loading a very large game and textures can be stored in the page file. This is when you would want the pagefile on the fastest access time and burst read drives, in your case the Raid0. Now if you were doing a processor intensive application that was dealing with large files on your Raid0 you would want the pagefile on the drive you aren't using... the slower one. There is another option, enable it on both. Windows XP is actually pretty smart when it comes to spreading the load. If one drive has large activity by a process it'll use the pagefile on another less used drive and vice versa. That's my approach. Personally I have an Intel Matrix Raid0 that is split into 2 partitions, a 60GB fast where Windows and programs reside, and a 3GB part for the swap file. The rest is a Raid1 of my images and various storage folders. I also have another 250GB drive I use for downloading too so that it doesn't effect gaming. The pagefile is only on the 3GB part of the Raid0 so it's fast and doesn't get packed into my drive image xml files :) . Awesome program if you haven't used it, highly recommended (it's free). Just make sure you use BartPE with it so that the restores are even easier.
So as you can see, for some it might be ideal to have it on the faster, others the slower, some others both, it doesn't really matter in the end because Windows XP is pretty darn smart about the page file... too bad the same can't be said about the RAM ;)
 
Gigabytes iRAM is the best solution that I've seen for a really fast pagefile system, and using it for a pagefile or scratch drive is the only really useful application for one of these.

It'll be expensive to populate to 4GB - but you will have the fastest pagefile system available today.
 
There is another option. I believe it's possible to create a RAM drive, and actually have the page file on RAM. Basically, from what i've read, it defeats the object of the page file anyway so there's probably little point reading up on this idea.
 
Maybe if you have a server mobo or something with more than 8 gigs of ram in it, but even with 4 gigs of ram i see that making little sense.
 
put it on a separate HD then your OS

I'd say put it on a seperate hard drive to what your most used programs are on. If all of your programs etc. are on a different hard drive than your OS, then i'd put the page file on the OS drive.
 
Maybe if you have a server mobo or something with more than 8 gigs of ram in it, but even with 4 gigs of ram i see that making little sense.

I agree - a ramdrive using system ram wouldn't work for most of today's systems.

Presently, I've limited my pagefile size to 4GB and it almost never gets filled up.
Which, is 2X the amount of RAM that I've got.

The old "rule of thumb" was to set the pagefile to 1.5X the amount of system RAM.
So, the iRAM is big enough for me and way bigger than most of the over the counter PCs sold today to use as a page file drive.

Plus, it transfers data at near the rated 150GB/sec over a SATA150 interface.
A Raptor can't do that, maybe one of the U360 SCSI drives can, but I don't think so.
 
Is it just me or is something wrong here? Whenever I read these posts I always get that feeling that everyone refers to page file as extra ram?

The way I learned it was a concept of Virtual Memory. For instance if the page file is turned on the memory is paged. Which this means is bits of memory are stored as pages which then the memory can store in the hard drive.

Me thinks that the biggest benefit is not the location of the page file, but no page file or all. This is dangerous though for system stability.

I think the biggest benefit would be more ram or a faster hard drive? Correct me if I am wrong.
 
I think it's just a placebo effect of dicking around with OS settings and you should leave it alone, as the OS configures it.
 
I generally have multi HDD systems, non-RAID
I set up 10GB partitions on outer tracks of each non-OS HDD to use for pagefile and scratch disk (for apps that use scratch, like PShop.
I set minimum pagefile size on OS disk.
 
I think it's just a placebo effect of dicking around with OS settings and you should leave it alone, as the OS configures it.

If you're running something intensive, like loading a large game, from a drive with a page file on it and the system starts paging information out of ram, you will take a small performance hit. Larger depending on how intensive it's doing the loading and paging.

Those read/write heads can only move back and forth so fast.
 
I generally have multi HDD systems, non-RAID
I set up 10GB partitions on outer tracks of each non-OS HDD to use for pagefile and scratch disk (for apps that use scratch, like PShop.
I set minimum pagefile size on OS disk.

If having the page file on the same drive as, but on a seperate to, the data being paged doesn't it cause head-thrashing since the drive had has to move between the 2 partitions? I suppose this is where multiple page files come in handy, right?
 
If having the page file on the same drive as, but on a seperate to, the data being paged doesn't it cause head-thrashing since the drive had has to move between the 2 partitions? I suppose this is where multiple page files come in handy, right?

The data being paged is going in/out of memory.
It has been years (>5 drive generations) since I tried to test performance results. When I did last test, PShop was only app that seemed to produce any change (single digit %). I suppose trying to test current media manipulation apps might be in order......
If you are interested in this, you might do a search on<pagefile multiple drives>
 
The data being paged is going in/out of memory.
It has been years (>5 drive generations) since I tried to test performance results. When I did last test, PShop was only app that seemed to produce any change (single digit %). I suppose trying to test current media manipulation apps might be in order......
If you are interested in this, you might do a search on<pagefile multiple drives>

Originally, i thought it would be best to put the page file on the first 4GB partition on my 36GB Raptor OS drive (and another 150GB raptor would be used just for games). But, wouldn't this wear out the 36GB Raptor due to excessive drive head movement betweent the pagefile partition and OS partition?
 
I have my two hard drives running separately now and I put the pagefile on the second HD. It does seem to work well for me but I certainly have no "proof" anything is faster now.

An old tip I still do - set the pagefile min/max to the same amount. And I think I have mine set to 3 GBs (1.5x), which would be pretty hard for me to fill up.
 
imho: if you're shelling out $$ for raptor raid, then it's probably worth putting enough ram in so you can turn off the swap file altogether. You get a small boost out of windows not trying to pro-actively swap all kinds of stuff to the file.

In theory, swap file should be an emergency scenario, but that doesn't seem to be how windows handles it (ram is actually cache for the swapfile?).
 
imho: if you're shelling out $$ for raptor raid, then it's probably worth putting enough ram in so you can turn off the swap file altogether. You get a small boost out of windows not trying to pro-actively swap all kinds of stuff to the file.

In theory, swap file should be an emergency scenario, but that doesn't seem to be how windows handles it (ram is actually cache for the swapfile?).

Disabling the pagefile completely is a bad idea. Even if Windows has enough RAM, some data is still paged onto the pagefile area on the hard drive.
 
It's impossible to disable the pagefile in the first place. Anyone that thinks just checking a box or radio button will disable the pagefile is sadly mistaken and needs to go back to 'puter school, really. Since the pagefile is just a small part of the entire virtual memory subsystem, it's simply not possible to "turn it off" on a whim.

Windows will always have a pagefile regardless of whatever settings the user decides to alter from the defaults - bad idea - and regardless of how much physical RAM the user has installed - so much for "the user knows best."

Someday I'll get to go a whole week without seeing these kinds of posts... ;)
 
Disabling the pagefile completely is a bad idea. Even if Windows has enough RAM, some data is still paged onto the pagefile area on the hard drive.

That's what I'm saying... windows tries to proactively swap pages out so that it takes less time to allocate new memory should it get caught in a bind. There's no reason why windows MUST be able to swap. It is true that windows (and all other OSs) regard swap as the "main" (albeit virtual) memory space, and ram as the cache, but that doesn't mean you have to permit it to use swap.

You CAN run with NO swapfile in XP, just as you can with linux or pretty much any other OS. When you run out of memory in XP, it will either give you an out of memory error or simply do nothing (from the user perspective). In other OSs, you will get a memory allocation error/exception since they DO check results of allocation requests.
 
It's impossible to disable the pagefile in the first place.
Sorry, but that's not correct. Running without a page file is different than running without paging; indeed, it is impossible to run without paging. But it's perfectly possible to run without a page file.
 
Sorry, but that's not correct. Running without a page file is different than running without paging; indeed, it is impossible to run without paging. But it's perfectly possible to run without a page file.

Where would the files get paged to; RAM drive?
 
Sorry, but that's not correct. Running without a page file is different than running without paging; indeed, it is impossible to run without paging. But it's perfectly possible to run without a page file.

There's an inherent flaw in that statement above: if it's impossible to run without paging, then obviously the pagefile is where those pages need to go, correct? Hence the dilemma that everyone claiming to run without a pagefile suddenly finds themselves in - "I don't have a pagefile, but Windows is paging, and I don't understand why?" So I'll explain.

Windows will create a pagefile automagically, a smallish one and use it as necessary. Typically it's about 20MB and will appear in the Windows\System32 directory as required so, the user might think they've pulled off some coup in the process, but Windows still knows how to handle things best and Windows will still have a pagefile when it needs one, which actually turns out to be most if not all the time.

So, in the long run, you're not running without a pagefile - you're just running without a user specified one, and paging operations will still occur as necessary.

The entire point is the same three word answer I've been giving for almost 2 decades now:

Leave it alone.

You (meaning the person reading this) will do more harm to the performance of your system in the long run by "disabling the pagefile" than not. Some of you (meaning the people reading this) might have enough RAM to lessen the need to page data to the pagefile to such a degree as it's not as noticeable, but the paging will still occur - and if Windows suddenly does need some serious virtual memory, stand back and go get a cup of coffee or something when it manually creates space for a much larger pagefile than you imagined you were going to see.

Talk about a performance hit...
 
There's an inherent flaw in that statement above: if it's impossible to run without paging, then obviously the pagefile is where those pages need to go, correct?
Incorrect.

A page in memory can be read-write, or read-only. An example of a read-write page is a page that's been allocated for private data by a program, then modified. An example of a read-only page is a page that's been loaded from an executable file on disk; the page is full of code, or read-only data, and can't be modified once in memory. (There's a few other details, like memory that's been marked "discardable".)

A page in memory is also "backed". The backing describes what out-of-memory storage can be used to swap the page in memory. Read-only pages are backed by a file on disk. Since they're read-only, there's never any modified data to write back out. If the OS needs to discard such a page, it just marks the page as not being used, knowing that it can always re-read the page from the appropriate place executable file on disk.

Read-write pages may be backed by the page file. This is the case if they're part of a memory-mapped file without a specific file, or if they're dynamically allocated memory from the Windows heap. Pages backed by the page file can't be swapped out if there's no page file.

Read-write pages may be backed by a file other than the page file, though; a programmer gets started setting this up with a call to CreateFileMapping() . Such pages will swap out to that file just fine when there's no system page file to use.

Even without a page file, then, Windows will page read-only data from executable image files all over the place. And it can page read-write data to memory-mapped files that applications have created. Neither of these operations involves, or requires, a page file.

(I think this explanation answers your similar question, Mansize_tissue; if it doesn't, please let me know.)

Windows will create a pagefile automagically, a smallish one and use it as necessary. Typically it's about 20MB and will appear in the Windows\System32 directory as required so,
This used to be the case, but isn't any more. Windows 2000 would create such a file, for instance. But Windows 2003 Server (and newer) and Windows XP (and newer) don't create a temporary system paging file.

Certainly, I agree that most people don't need to be touching the page file settings. They also shouldn't be overclocking, either&#8212;but people want to play with stuff and try to get more for nothing.
 
Any questions about my explanation? I'm happy to help, if so.

Meanwhile, to the question of where to place the page file, I think the most viable advice was given by needsnumbers: split it across both. This'll let Windows decide where to swap, hopefully using the disk that's least busy both at the time the page is written and the time it is read back in. I don't believe this algorithm takes any performance information about the target drive into account.

I haven't read anything that explains the algorithm Windows uses to decide where to swap to, or test it to see how it works. But it seems a reasonable approach.

I'm not positive putting the page file on the RAID 0 disk is a great idea. I haven't benched dual Raptors against a single drive, so I don't know how it works out, but I'd be worried that the latency for fetching from the RAID 0 disk is worse than from the single drive.
 
I have a question; well, it's more of a concern really. :)

Won't the page file cause the data to fragment on which ever drive it's put on? (Hey, maybe it was a question afterall!) I don't want to put a pagefile on a Raptor dedicated to game installs and have increased game stuttering because the files are fragmented all over the place.
 
You can force the page file to be preallocated. Then, it doesn't get fragmented itself, and it doesn't grow or shrink to cause fragmentation of other files on the same volume.

Fragmentation of the page file itself doesn't matter much as most I/O to it is random, anyway.
 
You can force the page file to be preallocated. Then, it doesn't get fragmented itself, and it doesn't grow or shrink to cause fragmentation of other files on the same volume.

Fragmentation of the page file itself doesn't matter much as most I/O to it is random, anyway.

How do you force it to be preallocated? Can this be achieved by simply setting it as a static pagefile?
 
Yes. So, set it to a static page file; set it to the same min and max size. Then, reboot -- that creates the file. If you want to run a defragmenter that defragments the page file, then you can do so, but you'll have to reboot again.

I've read conflicting advice about the system-managed file not becoming fragmented, but I don't believe it. I know, for sure, that a static sized file won't fragment.
 
Yes. So, set it to a static page file; set it to the same min and max size. Then, reboot -- that creates the file. If you want to run a defragmenter that defragments the page file, then you can do so, but you'll have to reboot again.

I've read conflicting advice about the system-managed file not becoming fragmented, but I don't believe it. I know, for sure, that a static sized file won't fragment.

Oh right; thank you. So when i do a clean install of Vista (with 2GB of RAM, maybe 4GB) i will immediately set the min. and max. values for the pagefile to aboue 1500MB or something, right? It's just a pitty it won't stay at the first part of the hard drive by itself.
 
Oh right; thank you. So when i do a clean install of Vista (with 2GB of RAM, maybe 4GB) i will immediately set the min. and max. values for the pagefile to aboue 1500MB or something, right? It's just a pitty it won't stay at the first part of the hard drive by itself.
Set them to whatever you'd like. I'm not sure what good placing the file "at the first part of the hard drive" would do. What makes you think it'll move?
 
Set them to whatever you'd like. I'm not sure what good placing the file "at the first part of the hard drive" would do. What makes you think it'll move?

If it's on the outer edges then seek times should be lower and transfer rates should be higher. It's not just going to stay in one place on the drive, is it? Because when other files move around, the pagefile will also have to move around to accomodate them. I just don't want the pagefile being pushed to the inner part of the drive because it will take longer for the drive head to seek to that area.
 
If you defragment, I suppose the defragmentation tool can move the file. But that doesn't happen otherwise.

Why do you think seek times are faster at the outer edge of the platter? Do you mean seek times from anywhere to the outer edge, from the other edge to anywhere else, or just within tracks at the outer edge?
 
I mean seek times from when the drive isn't active, so the head is in its normal static position, to seeking to the outer edge of the drive.
 
Where is the head's normal static position? Are you talking about a crash prevention parking feature?

I always thought track-to-track seek times were pretty constant, regardless of the distance, because the head accelerates sharply, stops sharply, and doesn't travel a great distance. Plus, most of the latency is in settling and waiting for the platter rotation.
 
I've read conflicting advice about the system-managed file not becoming fragmented, but I don't believe it. I know, for sure, that a static sized file won't fragment.
Unless Windows allocates an amount of space equal to the max amount, I can't imagine how that could possibly work. If a file resides on a number of sectors after the end of the page file (the min value), it would necessarily have to fragment the page temporarily to accommodate that. This won't fragment the page file up to the min amount (because Windows will inevitably release allocated sectors as page usage decreases), but it will lead to possible fragmentation of files created during the time that the page file has increased in size beyond the min value.

If Windows is blocking out space on the drive up to the max value, then you may as well just set the min value to the max value and be done with it. With hard drive space being as cost-effective as it is today, I can't imagine why SP2 didn't force a static page file.

Oh, and it seems like some of you guys have some pretty obscene page file sizes. I'd be surprised if some of you with 1GB+ page files would see any detriment from going down to 250MB or less. The 1.5x rule may have made more sense in 1997, but this is 2007.
 
Unless Windows allocates an amount of space equal to the max amount, I can't imagine how that could possibly work.
Right. The link I'm thinking of came up the last time I had this discussion on this forum -- within the last six weeks, say. The link claimed that the page file was, indeed, preallocated to the maximum size. I don't believe that's true.

If Windows is blocking out space on the drive up to the max value, then you may as well just set the min value to the max value and be done with it. With hard drive space being as cost-effective as it is today, I can't imagine why SP2 didn't force a static page file.
Right.
Oh, and it seems like some of you guys have some pretty obscene page file sizes.
As you say, drive space is cheap. If a 320 gig drive costs $85, then 4 gigs of space costs $1.06. How much does E_OUTOFMEMORY cost?
 
Where is the head's normal static position? Are you talking about a crash prevention parking feature?

Kind of. I just mean when the hard drive isn't active and the head is parked near the outer edges of the drive.

Plus, most of the latency is in settling and waiting for the platter rotation.

If a lot of the latency is caused due to the drive head waiting for the platter to rotate then, surely, due to the higher rotational speeds of the out platters on the drive latency will be reduced.
 
Back
Top