What is the final word on the Win XP page file(s)?

[DanHonemann]

OK, so folks used to advise putting the Windows paging file on a different drive (and even better if the drive is off a different controller) than the OS, BUT now it turns out that doesn't make all that much difference performance-wise and most folks advise just leaving it on the OS partition.

And then folks used to advise setting the min and max page file size to the same amount, usually 1.5x RAM or whatever, i.e., create a static-sized page file in order to prevent it from fragmenting and otherwise slowing down the system, BUT now I read that it is best just to let Windows itself manage the size of the file.

Have I got my conclusions right? Or do I need to read another thousand pages and links on the subject?

Can I just change my current settings (from min 1536 MB and max 3072 MB on a laptop with 1 GB total RAM) to the "System managed size" option and reboot, or do I need to go through some rigmarole with deleting the existing page file first, rebooting into Safe Mode, defragmenting, running this-or-that page file defrag utility, etc. first?

Note: I'm no expert, just maybe a rung higher on the ladder than noob status, have never installed or run Linux, and am only interested in running a stable system, not tweaking every last drop of performance from it.

Thanks,
Dan

 

[MrChad]

Your conclusions sound fine to me, but I'm sure this thread will drag on for pages, as there are hundreds of lurkers on this forum who insist they know pagefiles better than Microsoft.

 

[DanHonemann]

Yep, how well I know... I've read through many of those threads, found them to be entertaining at first, then exhausting. I find it highly ironic that after so much research I've come to the conclusion that the best approach to such an apparently controversial subject is to do nothing at all--just accept the Win XP default which is a single page file on the OS partition that the system manages.

Dan

 

[nweaver]

I found a doc on Microsoft's KB that said use it off drive if possible (yesterday, have to see if I can dig it up later). I still prefer the static sized page file, but ymmv.

 

[Navid]

This is what Microsoft has to say about it.
http://support.microsoft.com/default.aspx?scid=kb;en-us;555223

From that link:
A frequently asked question is how big should I make the pagefile? There is no single answer to this question, because it depends on the amount of installed RAM and how much virtual memory that workload requires.

As you can see, there is no one answer. There are pros and cons with any one setting. That is why the best answer for one is not the same for another.

Here, you can see more about how to set up the pagefile, again from Microsoft.
http://www.microsoft.com/windowsxp/home...uctdoc/en/computer_maint_perf_mgmt.asp

I think if Microsoft thought that the best thing to do was to leave the pagefile alone, they would not publish these notes.
http://support.microsoft.com/default.aspx?scid=kb;en-us;314482

But, you have to realize that you may not get any benefit or even reduce performance if you don't do the right thing. For example, if you put your pagefile on a slow physical hard drive, you may reduce performance. Or, if you have enough RAM, you may never see a difference in performance.

So, try different settings and compare the results.

 

[Wicked2010]

If you are talking about a desktop computer, then it makes no difference really if you keep it on the OS partition.

Now, if you are talking a server environment... then a different disk is recommended. Especially if the server has 2 GB of RAM or more.... since the paging file will need to be pretty large. Also since you will be using SCSI drives, it's going to be noticeable.

 

[MrChad]

Static page files seem inefficient to me (it will either use more space than necessary, or it will not be enough space and throw errors).

Here are some Microsoft articles on the subject.

RAM, Virtual Memory, Pagefile and all that stuff
Configuring page files for optimization and recovery in Windows Server 2003, in Windows 2000, and in Windows NT

 

[Smilin]

Originally posted by: nweaver
I found a doc on Microsoft's KB that said use it off drive if possible (yesterday, have to see if I can dig it up later). I still prefer the static sized page file, but ymmv.

Yeah, I've read that KB at one time or another as well as the internal version of it. Placing your pagefile on a separate drive will show some performance gains. These are usually trivial gains unless your main drive is being hammered by some SQL database or something. Placing it on a separate partition on the same drive to "avoid fragmenting" is straight up retarded.

Keep in mind if you move your pagefile off of your boot drive you will be unable to obtain a memory dump in the event of a kernel crash. This never sounds like a big deal until it's suddenly a big deal!


Although I am clearly an idiot for being suckered into responding to this thread my advice is still sound: Let Windows handle it.

 

[DanHonemann]

Seems to be a never-ending battle between the static- vs. dynamic-sized page file groups. I've always used a static-sized page file, but the arguments to just let Windows handle it do make sense to me.

A more compelling argument can be made with regard to location; it does make sense to offload the page file to another drive (on another controller). Unfortunately for me, I'm a heavy Photoshop user, and PS wants its own swap file to be on a different drive/controller than the windows swap file (and its own program files). So, unless I want to have three separate controllers onboard (I don't), I'll stick with my current arrangement: OS and swap file on C: drive, PS swap file on separate hard disk & controller.

Dan

 

[DanHonemann]

Originally posted by: DanHonemann
it does make sense to offload the page file to another drive (on another controller).

Er, at least it did until I read Smilin's post above.

Seems my initial conclusions are best (let Windows handle it, period) unless someone can offer hard evidence (real world performance figures) to the contrary.

Dan

 

[Smilin]

uh, which part?

whuddeye say?

 

[nweaver]

Originally posted by: MrChad
Static page files seem inefficient to me (it will either use more space than necessary, or it will not be enough space and throw errors).

In this day and age of huge HDD's, it's not going to matter if you waste some space on an extra large page file.


As for static, I have seen a fragmented page file cause problems on my exchange server. I could not mount my mailstore anymore. After a defrag (rest of drive was ok, just pagefile issues) then it was working fine. At the time, I had it windows managed.....

 

[DanHonemann]

Originally posted by: Smilin

uh, which part?

whuddeye say?

You said:

> . . . my advice is still sound: Let Windows handle it.

Agreed,
Dan

 

[DanHonemann]

Originally posted by: nweaver
As for static, I have seen a fragmented page file cause problems on my exchange server. I could not mount my mailstore anymore. After a defrag (rest of drive was ok, just pagefile issues) then it was working fine. At the time, I had it windows managed.....

Yeah, servers are clearly a whole nother can of worms.

But for single-use desktop PC's, it seems fine to just let Windows do its thing. Fine and maybe even best.

Dan

 

[bsobel]

Best advice I can give you is to have more physical ram than your actually using so your not actually paging (just creating reservations).

 

[DanHonemann]

Originally posted by: bsobel
Best advice I can give you is to have more physical ram than your actually using so your not actually paging (just creating reservations).

Excellent advice which I severely wish I could follow but my crappy Dell Dimension 8250 is maxed out at 1.5 GB of RDRAM.

Naturally, I bought this PC two years ago before I discovered anandtech and similar sites and enlightened myself (however slightly) to much better options.

Next time....

Dan

 

[montag451]

Hey this is great - I got 1gig RAM, and whatever I load up - the count never goes to below 550MBfree physical and 220MB PF (used) out of 800MB set aside for it.

(I'm not a gamer as you can prob tell)

 

[KoolDrew]

Originally posted by: MrChad
Your conclusions sound fine to me, but I'm sure this thread will drag on for pages, as there are hundreds of lurkers on this forum who insist they know pagefiles better than Microsoft.

 

[VirtualLarry]

Originally posted by: bsobel
Best advice I can give you is to have more physical ram than your actually using so your not actually paging (just creating reservations).

Except no matter how much RAM you have, allowing paging can actually increase performance, in many/most cases - up until you start thrashing, and paging activity consumes the majority of I/O bandwidth, and most processes are stuck in an IOWAIT rather than a RUNNING state.

 

[bsobel]

Originally posted by: VirtualLarry

Originally posted by: bsobel
Best advice I can give you is to have more physical ram than your actually using so your not actually paging (just creating reservations).

Except no matter how much RAM you have, allowing paging can actually increase performance, in many/most cases - up until you start thrashing, and paging activity consumes the majority of I/O bandwidth, and most processes are stuck in an IOWAIT rather than a RUNNING state.

No matter how much ram you have, paging increases performance?

 

[VirtualLarry]

Originally posted by: bsobel
No matter how much ram you have, paging increases performance?

Yes. It's a very subtle nuance of most modern OS that are capable of both virtual-memory paging using a pagefile, as well as RAM-based caching of disk block I/O. Dumping "stale" pages to the pagefile, allows freeing up RAM, to serve as a read-ahead/write-behind disk cache for the currently active processes.
In fact, MS documents this, I found it while researching for a different thread. link

The Windows 2000 operating system supports virtual memory. With virtual memory, a special file on a hard disk (known as a page file or a swap file) is used to supplement the physical memory installed on a computer. When a computer begins to run low on physical memory, data can be "swapped out" to the page file. This has the following advantages:
It frees up physical memory.
It makes it relatively fast and easy to retrieve the data, because the system knows exactly where to look for it.

Page files and virtual memory are extremely important to fast and effective computing. Without page files, computers would need double or triple the amount of physical memory in order to achieve the same level of performance.

Interesting, isn't it? It's because paging effectively multiplies the amount of physical RAM, allowing it to serve multiple duties at different times. This is more flexible, and thus offers the potential for greater performance, than if it wasn't flexible. This is also why that often-mentioned "DisableExecutivePaging" setting, can actually reduce performance if enabled.

It's similar to CPU scheduling timeslices - increasing the timeslice size results in greater actual CPU utilization (due to less schenduling overhead), at the potential cost of interactive responsiveness. Same thing with paging, it can increase performance, but potentially decrease interactive responsiveness, compared to disabling the paging file altogether and only using RAM. (Ok, technically, you would also have to pre-load and lock non-dirty backing-store pages like .DLLs and .EXEs into RAM too, for the ultimate in in-RAM responsiveness.)

 

[Spencer278]

Originally posted by: bsobel
Best advice I can give you is to have more physical ram than your actually using so your not actually paging (just creating reservations).

You want to donate a gig of ram so that I can get ride of my 768 MB page file? It is a waste of money to have more ram then your ever going to use. Especially true if you are a heavy multitasker. Why pay for enough memory to store all 19 or so programs when I can only use one at a time.

 

[bsobel]

Originally posted by: VirtualLarry

Originally posted by: bsobel
No matter how much ram you have, paging increases performance?

Yes. It's a very subtle nuance of most modern OS that are capable of both virtual-memory paging using a pagefile, as well as RAM-based caching of disk block I/O. Dumping "stale" pages to the pagefile, allows freeing up RAM, to serve as a read-ahead/write-behind disk cache for the currently active processes.

Larry, (shaking head). This is absurd. Not paging is prefereable to paging. I can't believe even you'd argue this.

 

[bsobel]

Originally posted by: Spencer278

Originally posted by: bsobel
Best advice I can give you is to have more physical ram than your actually using so your not actually paging (just creating reservations).

You want to donate a gig of ram so that I can get ride of my 768 MB page file? It is a waste of money to have more ram then your ever going to use. Especially true if you are a heavy multitasker. Why pay for enough memory to store all 19 or so programs when I can only use one at a time.

The original poster was talking about even using a second drive for page file storage. Memory is cheaper.

Bill

 

[VirtualLarry]

Originally posted by: bsobel
Larry, (shaking head). This is absurd. Not paging is prefereable to paging. I can't believe even you'd argue this.

I can't believe that you're unaware of the performance advantages of a paging file. (Seriously. ) Let me dig out some references. This facet of paging relative to performance is also fairly well-known to *nix kernel hackers too. (Although I am not one of them.)

I guess it depends on whether you demand the utmost level of interactive responsiveness, or prefer overall higher performance. (I did mention, it enhances performance, only up until it reaches the point of "thrashing" - I'm not suggesting that phenomenon is in any way performance-enhancing, and in fact it signals that you don't have enough physical RAM period.)

Btw, freeing up physical RAM, for more useful immediate purposes, was precisely the function for the swapfile (not pagefile) in VMS, too. Except that entire process address-spaces were swapped to that file instead of individual pages (which were paged to a seperate VM pagefile as well).

Edit: Btw, to help you understand, re-word your sentance to read "Not caching disk blocks in RAM is preferable to caching them." Does that make any sense, in terms of performance? Yet, that's exactly what will occur, if paging is disabled, and physical RAM cannot be dynamically freed on-demand to use for disk caching, but instead forced to remain storing "stale" application memory pages.