Page File Question!!!

[swirly]

Hey, I have 2GB of ram, and I used to have my settings as initial 512mb and max 1536, everything runned great, but now I added another gb, so now everything is runing choppy, I am getting these blue screen errors which is caused by page files and shit.. So, should I put it on 512/1536? I am asking this because I got the bf2 dmeo and I have:

Geforce 6600GT
2GB DDR400
AMD 64 3400+

And I have to run it on lowest settings WITH LAG!!

Well, tell me what to change it to and what it will be doing!!

THANKS SO MUCH IN ADVANCE!

[dandragonrage]

Sounds like your RAM timings are too tight. Try Memtest86+.

[swirly]

Not what I wanted to hear lol ;).. I mean, I need to set my page file, should I set it back to 512/1536?

[daglesj]

If you have 2Gb of ram I'd just set your swappy to 512/512 and leave it at that. Then your harddrive (on the odd occasion when your swapfile is accessed for some reason) wont go off on a dynamic resizing excercise.

As said previous, I'd say its your ram. You havent got a DFI board by any chance? That aside it seems a lot of A64 boards (especially NF4) seem very edgy when it comes to using more than a gig of ram.

[KoolDrew]

Just leave the pagefile System Managed. There is no reason to mess with it unless you encounter problems caused by the pagefile and as others have said it does not sound like a problem caused by the pagefile.

[Carnival Forces]

Just leave the pagefile System Managed. There is no reason to mess with it unless you encounter problems caused by the pagefile and as others have said it does not sound like a problem caused by the pagefile.
read a sticky lately?

making your pagefile static is a great way to "speed up" (i.e. make more efficient) your computer.

[swirly]

I am pretty sure the page file is what is causing me to lag in bf2, I have:

Geforce 6600GT
2GB DDR400
AMD 64 3400+

And I have to play on low settings?? HMM?? Ya well, can I change heapsize, or the amound of ram the game uses? Or page file or somehting to get me way better looks + performance..

[KoolDrew]

read a sticky lately?

making your pagefile static is a great way to "speed up" (i.e. make more efficient) your computer.

Making your pagefile static will have no affect on performance. All it does is remove that "safety net" if it come to a point where the pagefile needs to resize.

I don't need a sticky to tell me how Windows functions.

[djnes]

If you have 2Gb of ram I'd just set your swappy to 512/512 and leave it at that. Then your harddrive (on the odd occasion when your swapfile is accessed for some reason) wont go off on a dynamic resizing excercise.
It's a good common practice to set the pagefile to a static size...not in the name of performance per se, but in the name of cutting down on some disk defragmentation. Set it to 512/512 and see how it goes. I doubt you'd have to resize it any more than that.

[KoolDrew]

but in the name of cutting down on some disk defragmentation.

It will have no affect on fragmentation. If you set the initial as 512MB and the max at 1GB (just random numbers) and it comes to a point where a larger pagefile is needed it will be temporarily resized to accomadate for the need. After a reboot the pagefile will revert back to its initial size so there will be no fragmentaion. Also if the initial is set high enough the pagefile will most likely never have to resize anyway.

Setting the pagefile a static size is just a bad idea. Setting it dynamic does not cause windows to "resize" it endlessy.

[djnes]

It will have no affect on fragmentation. If you set the initial as 512MB and the max at 1GB (just random numbers) and it comes to a point where a larger pagefile is needed it will be temporarily resized to accomadate for the need. After a reboot the pagefile will revert back to its initial size so there will be no fragmentaion. Also if the initial is set high enough the pagefile will most likely never have to resize anyway.

Setting the pagefile a static size is just a bad idea. Setting it dynamic does not cause windows to "resize" it endlessy.
If your writing files to the disk when the pagefile is "expanded", it can and will create excess defragmentation. I know your passionate about this topic and it's debates, and usually I agree with you, but this one is a tried and true fact from back in the NT 4.0 and Win98 days, and still exists.

[Phoenix86]

Static PFs will prevent it from getting fragmented but honestly, with common use and 2GB of RAM his PF will never expand regardless of his settings. Unless he uses a shit ton of memory, so...

What is your expected commit charge peak? IE how much memory do the processes running on your setup take?

Read me. (http://www.hardforum.com/showthread.php?t=820472)

KoolDrew, if you don't believe me test this. Get a low memory system and start using it, make sure the PF expands. Reboot. Use it more (IE increase commit charge from the previous boot session to re-expand the PF). Repeat this process about 20 times. Now view the page file through a defragmenter that'll see it.

The scenario I just layed out describes typical use over time. As a user gets more software installed on the the memory usage goes up. Spyware makes this worse, esp if it's buggy and has memory holes (I have run into several). Heck, any program with a memory hole will fragmented the hell out of the PF, all this of course over time.

edit: a good defragger, one that will defrag the PF, is a "cure" to this, I didn't see that questions asked.

To the OP,
Other than that there are likely no settings that will affect performance. You likely have enough RAM, and aren't using your PF much at all. So making changes to the PF won't affect you.

[KoolDrew]

If your writing files to the disk when the pagefile is "expanded", it can and will create excess defragmentation. I know your passionate about this topic and it's debates, and usually I agree with you, but this one is a tried and true fact from back in the NT 4.0 and Win98 days, and still exists.

A pagfile is not any different from any other file. When the pagefile expands yes, it does create a "hole" causing fragmentation, but so do log files the system is always writing to.

There is absolutely no benefit to a static pagefile. It is just a bad idea. Period.

Static PFs will prevent it from getting fragmented but honestly, with common use and 2GB of RAM his PF will never expand regardless of his settings. Unless he uses a shit ton of memory, so...

Exactly my point. With a high enough initial the pagefile will nerver have to expand anyway. If however you do come under an extremely heavy load and it does need to expand it can. There is no benefit from using a static pagefile.

KoolDrew, if you don't believe me test this. Get a low memory system and start using it, make sure the PF expands. Reboot. Use it more (IE increase commit charge from the previous boot session to re-expand the PF). Repeat this process about 20 times. Now view the page file through a defragmenter that'll see it.

I don't get your point at all.

Heck, any program with a memory hole will fragmented the hell out of the PF, all this of course over time.

If you mean a memory leak then yes if the pagefile is too small. This is why you make the initial large enough for any anticipated use.

There is absolutely NO reason at all to use a static pagefile preventing the pagefile from expanding when it is necessary.

[djnes]

There is absolutely NO reason at all to use a static pagefile preventing the pagefile from expanding when it is necessary.
There are plenty of reasons listed above. As you yourself said, the pagefile is just like any other files. That being said, knowing how data is written to a drive, you'd see why you'd want this file static.

[Phoenix86]

KoolDrew, if you don't believe me test this. Get a low memory system and start using it, make sure the PF expands. Reboot. Use it more (IE increase commit charge from the previous boot session to re-expand the PF). Repeat this process about 20 times. Now view the page file through a defragmenter that'll see it.
I don't get your point at all.
Just because you don't get it, doesn't mean there isn't a point. ;) The point is, over time, under normal use, a system's PF can and will get fragmented. Too much fragmentation=poor performance. Even more can lead to system instability, I have seen it myself.

The method I gave you above will demonstrate how the PF gets fragmented and show you the performance hits.


If you mean a memory leak then yes if the pagefile is too small.
Think about this for a second. Programs with memory leaks know no bounds, except the PF size+RAM. If a programs is leaking memory it'll constantly grow the PF. Growing the PF increases fragments. Over time this is a problem. Leaking programs just make the problem more apparent.

This is why you make the initial large enough for any anticipated use.
I though you said to let the system manage it, you can't specify a minimum if the system is managing it. C'mon now, don't play moving targets.

There is absolutely NO reason at all to use a static pagefile preventing the pagefile from expanding when it is necessary.
Now you're being obtuse. I have clearly demonstrated SOME benefit to static size. If it's not the "best" approach, that's one thing, but there are benefits as well as caveats.

Be carefull with "absolute" statements.

[HTPC Rookie]

Would making say a 2GB partition on the drive, using it for nothing but the pagefile, set to auto resize, eliminate any frag worries?

[djnes]

Would making say a 2GB partition on the drive, using it for nothing but the pagefile, set to auto resize, eliminate any frag worries?
I may be wrong here, but I through for some reason it was shown that putting the pagefile on the same physical drive, but separate partition had a negative impact. I may be wrong, but I don't see anyone or any guides recommending this.

[Phoenix86]

I may be wrong here, but I through for some reason it was shown that putting the pagefile on the same physical drive, but separate partition had a negative impact. I may be wrong, but I don't see anyone or any guides recommending this.
It doesn't help, it increases seek times because the data is seperates from the other 95% of the system's data on the same drive. Also, it doesn't achieve anything more if you set the PF's max=partition size.

Remember, the whole fragmentation issue is when you're actually using the PF in the first place. If you have "enough" RAM you won't be, and most of this is moot.

[Grimmda]

I see this topic come up far more than I personally think it should here. By those of you so inclined to gain performance by doing one thing or another by altering your page file let me just ask this:

"At what point does altering your PF settings when you have 1 or 2 GB of RAM start to take effect"

and

"When those alterations begin making a difference what is the noticable performance increase?"

The OP has stopped responding at this point and has probably gone and set it back to what he had it at and finding that BF2 is still lagging because what he THINKS is his problem ISN'T his problem, and the rest of this post is the same BS "Pagefile" posturing.

So getting back to the original thread: swirly
Just set it at "auto managed" and let it be. You're problem isn't based on your Pagefile because I checked last night and the Demo only grabs about 400-550 MB of RAM anyways... And there is obviously that much free'ed up on your system. You're not the only one having this issue, you might want to read more in the Gaming forum...

[Phoenix86]

There is no "break point" that's not logical. It's based on the ratio of commit charge peak/RAM, IE memory usage vs. available RAM.

You're right though, with most peoples systems they have enough RAM. They can set the PF to just about anything, and performance won't be helped.

Best answer to all these threads is: have enough RAM to supply commit charge peak, otherwise you have a memory bottleneck.