Page File Tweak Is False

[Dirk Diggler]

Well I for one have no intention of arguing with the JEH.
When Dealer wants info he talks to the big-wigs, not us little folk.

 

[Sonny]

How to Configure Paging Files for Optimization and Recovery in Windows XP (Q314482)

 

[allan]

btw, re something else you wrote - there's no case in which XP (or NT, or 2K) EVER creates a pagefile on each disk! I routinely install XP on systems with multiple physical disks and I've never seen that behavior. Left to itself it simply creates one pagefile in the boot partition (that's the one with the \windows\... or \winnt\... directory), default size 1.5x RAM, max size 3x RAM.

On every XP system I've seen, the default setting is a paging file on every partition. This needs to be changed by the user.

 

[Perris Calderon]

So, I posed this question to jamie;

"So is anyone saying ceating a static pag file is counter productive?"

and I cut and pasted his answer here;

"Well... with a static pagefile, IF your estimate of your needed pagefile size is too small, apps will start failing due to lack of virtual memory. This could be considered a performance hit.

Other than that, no, a static pagefile doesn't hurt performance. It's just that it gives you no "safety net" in case your estimate of its size is too small.

Conversely, a dynamic pagefile doesn't hurt performance either, as long as the default size is large enough for your routine use of the system."

thank you jeh, and thanx everyone for this discussion

 

[Perris Calderon]

Ok, so here's what I've learned from doing more research on this issue...

I'm trying to put this in a users terminology, and not a teckies terminology.

Xp is a paging os...no matter what you do, xp will page...now this does not mean the os will use the paged information it creates, in essence, the os is just getting ready, and will still use ram, even though it's paging.

Turning off the paging file, because you have alot of ram will not speed the os, and will not prevent paging...xp will find somewhere else to page to.

Further, if you make the file too small, you'll get some error measages, and that's a slow down on it's own.

As far as being concerned about fragmentation when the file is dynamaic...not to worry, xp will only change the file size if it needs too...(technical terms, when the commit charge reaches the commit limit), otherwise, it's default is the size you would have created on a static file...see?...fragmentation is not an issue...unless you've needed the file bigger anyway.

Now, I understand that even when xp does change the file size, fragmentation is still not a performance issue...here's what happens...the file remains static, unless you are in dire need of a bigger file, then the file expands...fragmentation does occur here, HOWEVER...the file reverts back to the default on reboot...all data on the expansion is erased...no fragmentation...period...it does not happen

now if you decide that your pagefile is too small, because your pagefile did increasehappened, ( it is a good idea to permanently INCREASE the page files minimum size), you should defragment the pagefile with the pf defrag program I posted on the free programs thread... when you make the change to a bigger minimum page file size....that's it...the pf will absolutely never get fragmented...period...still, when you do increase the page files minimum size, keep expansion enabled...that's it, done...my recomendation for the best setting, 2x ram, expansion enabled to 4x ram

Basically, Your giving nothing up by letting xp manage your page file, as the default is the same size you would have created statically...but the dynamic nature of the default setting gives you a safety net, incase the correct file size is not enough...like a safety net, you'll probally never use...so it doesn't hurt anything to keep it there...

I think that's easy to follow...let me know if it's not, and I'll try again.