Finally found the app that made me re-enabled a pagefile.

djnes

Fully [H]
Joined
Mar 24, 2000
Messages
19,560
I have always, since going to a GB of memory years ago, ran without a pagefile. I've never had a problem, because I don't use Photoshop. However, last night (system in my sig) I got an "Out of Virtual memory" error after about 5 autosaves in Half Life 2. I've never had a problem, even with Doom3 and BF1942. So, I created a static 500 MB pagefile, and the game runs great now. I notice apps like Outlook and Word don't open as snappy, but it's hardly a difference worth complaining about.

Anyone else notice this?
 
djnes said:
I have always, since going to a GB of memory years ago, ran without a pagefile. I've never had a problem, because I don't use Photoshop. However, last night (system in my sig) I got an "Out of Virtual memory" error after about 5 autosaves in Half Life 2. I've never had a problem, even with Doom3 and BF1942. So, I created a static 500 MB pagefile, and the game runs great now. I notice apps like Outlook and Word don't open as snappy, but it's hardly a difference worth complaining about.

Anyone else notice this?
<nelson>
HAHA!
</nelson>

edit: damn it to hell. Your asking that question?
*popcorn, beer, lawnchair*
Maybe I'll sit this out for the first page or so. :)
 
There's definitely something to the snappiness. I notice with the pagefile enabled, if I open an Office app, my hard drive churns a lot more than if I do not have a pagefile enabled. We're not talking 20 seconds difference in loading time...it's not anything more than maybe a second or two. Yes I know...scientific, right? I'm keeping the pagefile though...I need HL2 to be stable. Nothing else seems to load any differently...just the office apps.
 
You could disable a bunch of services to save some memory and then you wouldn't need the PF anymore. I know this site... ^.^

;)
 
I'm not trying to drum up the performance issues. That topic ranks up there in annoyance alongside installing SP2 or not. I was just surprised to see the error, since I've never gotten it before.
 
I know, I'm just teasing you with my last post. ;)

I got it a bit on my work laptop (512 MB RAM) before I gave in and setup a PF. My memory requirement keep creeping up. Now I'm using ~650, about a year ago I was under 512. I'm still running the same stuff except I switched to firefox (I'm not positive but I think it uses more RAM than IE, have not tested/measured) and have upgraded versions on some of my DB software. I know the DB software upgrade added ~50, but that was just installed a few days ago. I really think it's web pages taking more RAM, not necessarly the browser.

Anyways, yes I noticed similar results, even when I'm not deep into my memory pool, just loading my first all (usually outlook) seems a hair slower with a PF. But it really doesn't matter? You either have the RAM to run no PF or not. You no longer do, getting more RAM is my actual recommendation. 1GB too much? I think no.

I'm wondering how long it'll take for us to start hitting the 3/4GB barriers. After all we went from machines with 128MB RAM to 512GB in about 2 years.
 
Outlook was definitely the app that showed the bigest difference. It's probably all the bloat it loads.

I'd hate to see what the upgrade costs will be once we need that much memory. :eek:
 
djnes said:
Outlook was definitely the app that showed the bigest difference. It's probably all the bloat it loads.

I'd hate to see what the upgrade costs will be once we need that much memory. :eek:
Well, mine is a work system I'm compraing it to, but then again my job requires a lot of apps... I don't think Joe user requires enough RAM to consider disabling the PF (edit: not that I'm saying a user ever should, I'm just refrencing that amt. of memory where RAM=memory requirements), they can live with some swapping.

Though recently my machine has been really choking when it's swapping and it's pissing me off. It'll take 2-4 minutes of prue I/O (HDDs getting hammered) when I launch new apps, like a word doc. While it's swapping I can't use the machine at all, it's 95% locked up. *twiddles thumbs while swapping* :mad:

Can't wait for the new machine, I requested a GB of RAM, we'll see... :rolleyes:
 
Phoenix86 said:
Well, mine is a work system I'm compraing it to, but then again my job requires a lot of apps... I don't think Joe user requires enough RAM to consider disabling the PF (edit: not that I'm saying a user ever should, I'm just refrencing that amt. of memory where RAM=memory requirements), they can live with some swapping.

Though recently my machine has been really choking when it's swapping and it's pissing me off. It'll take 2-4 minutes of prue I/O (HDDs getting hammered) when I launch new apps, like a word doc. While it's swapping I can't use the machine at all, it's 95% locked up. *twiddles thumbs while swapping* :mad:

Can't wait for the new machine, I requested a GB of RAM, we'll see... :rolleyes:

I'm posting on my Omnibook 6100 that has a 1000 Mhz P3 and 512 MB of memory. I know exactly what you mean. I click to open Outlook in the morning, and that's when I go get my coffee. And god help me if I have to nerve to right click on a Calendar entry.
 
I think the excess paging goes hand in hand with higher total memory usage. When total memory is higher, it needs to swap more from RAM to disk, increasing how long that swap takes...

Funny thing. My new desktop machine *just* arrived (HP). It's missing the extra 512 RAM, but it's on backorder but it's coming (WTF you guys ain't got another 512 stick for me? :p ).

I'm un-boxing it now.
 
Phoenix86 said:
I think the excess paging goes hand in hand with higher total memory usage. When total memory is higher, it needs to swap more from RAM to disk, increasing how long that swap takes...

Funny thing. My new desktop machine *just* arrived (HP). It's missing the extra 512 RAM, but it's on backorder but it's coming (WTF you guys ain't got another 512 stick for me? :p ).

I'm un-boxing it now.

I called our PC Division and told them to specifically withold your extra memory chip, just to enhance your total customer experience. TCE, baby!!!!!!!!!

I seemed to recall seeing a blurb on one of our intranet pages about a decrease in memory shipments to HP because of the tsunami....but I don't know much about it.
 
Sure blame on the tsunami...

You know, we could have just done this via PMs. ;)
 
Phoenix86 said:
Sure blame on the tsunami...

You know, we could have just done this via PMs. ;)

lol. So much for sitting out the first page or so ;).
 
There is no reason to set is static. When the pagefile is static it has no room to grow which is one of the major benefits of a pagefile.
 
KoolDrew said:
There is no reason to set is static. When the pagefile is static it has no room to grow which is one of the major benefits of a pagefile.

If you use some basic math to calculate the needed pagefile, you wno't ever need it to grow. On the flip side, it's a welldocumented fact that setting the pagefile to a dynamic size can and will lead to more fragmenting, and decreased performance of the virtual memory system.

We can all argue about having on or not, but the one part that is a definite fact is setting a static size, and moving the file to the outer edge of the disc.

Phoenix86, whip out your formula, and slap it down.
 
f you use some basic math to calculate the needed pagefile, you wno't ever need it to grow

How do you know that is all you will need?

On the flip side, it's a welldocumented fact that setting the pagefile to a dynamic size can and will lead to more fragmenting, and decreased performance of the virtual memory system.

That is incorrect. The pagefile will only increase in size if the min is not high enough. If the min is high enough the pagefile will never resize. This will give you the benefits you speak of a fixed pagefile, but it has room to grow if needed.

Also what do you mean by degraded performance? Do you mean defrageded performance when paging? If you do you are wrong. The pagefile is not read ina seqentual manner so a fragmented pagefile will have NO affect on the performance of paging.

You also should know the paging file is NOT the only file involved with paging. Because of this the head is jumping all over the place anyway.

The only way a fragmented pagefile can degrade performance is because since the pagefile cannot be moved other files may become fragmented. However this will NOT affect performance when paging to and from the pagingfile.

We can all argue about having on or not, but the one part that is a definite fact is setting a static size, and moving the file to the outer edge of the disc.

Both points are incorrect and should not be used. We alreay discussed setting a static size and how it is not reccomended. As for the outer edge of the disk all that would do is increase seek times. You want the pagefile near the most used data and since the pagefile is not the only file involved with paging the head of the harddrive will have to jump all over the place. If the pagefile is in on the outer edge the head will have to seek all the way across the disk
 
Well, I know what I will need, because I use my computer. Memory usage is a pretty easy thing to calculate.

As far as the performance issues, you should read more performance guides. They are pretty well documented, in the manuals of all disk defraggers I've seen. Microsoft also had several pages in Technet detailing the same things and how it improved performance. In fact it was demonstrated and discussed at the XP rollout conference I attended a few years ago.

I also have several contacts within Microsoft that I could verify this with if you'd like further proof.

I understand the pagefile grows only when needed....I wasn't disagreeing with that. But if you make a calculated decision, you don't need it to grow.
 
As far as the performance issues, you should read more performance guides. They are pretty well documented, in the manuals of all disk defraggers I've seen. Microsoft also had several pages in Technet detailing the same things and how it improved performance. In fact it was demonstrated and discussed at the XP rollout conference I attended a few years ago.

Most performance guides are terrible and give false info. Like this for example.
http://forums.anandtech.com/messageview.aspx?catid=34&threadid=1500375

What I said still stands. With the way the pagefile is acessed a fragmented pagefile will have no affect on performance when paging. The ONLY affect it will have is fragmentation of other files because the pagefile cannot be moved.

I understand the pagefile grows only when needed....I wasn't disagreeing with that. But if you make a calculated decision, you don't need it to grow.

But as I already said there is no benefit to hacing it static. Even if it does not need to grow there is NO benefit.
 
KoolDrew said:
Most performance guides are terrible and give false info. Like this for example.
http://forums.anandtech.com/messageview.aspx?catid=34&threadid=1500375

What I said still stands. With the way the pagefile is acessed a fragmented pagefile will have no affect on performance when paging. The ONLY affect it will have is fragmentation of other files because the pagefile cannot be moved.



But as I already said there is no benefit to hacing it static. Even if it does not need to grow there is NO benefit.

First, I said performance guides...not forum posts. There's a big difference in the validity of such. Your showing me with each post you understand less and less...same as the other thread where your battling with Phoenix86. When you move the pagefile to the outer edge of the disk, it does fragment the other file....until the defrag utility finishes. That's why diskeeper moves the pagefile during the boot process, and the runs it's defragger to sort out the rest of the files. Your moving farther and farther from the truth with each response, and your proof data is becoming less and less valid.
 
First, I said performance guides...not forum posts

The initial post was about a performance guide.... Also since the pagefile is not the only file involved with paging placement of the pagefile is pretty silly since every exe and dll your system is using is, in essence, a paging file. You can't put them all in the best spot.
 
GAH, 3 threads at once!!! *head aspodes* I am working you know.... ;)

BTW, that's one loud ass HDD you put in there djnes. Damn, it's a seagate too :confused: They are usually quiet, meh... Oh, right page files...

He's seen my formula, we're posting back and forth in that thread now. KoolDrew, people know how to size it based on the thread stickie. They determine their usage based on *actual* experiences with software on *that* machine. Not a "general guide."

PF=range with high minimum: OK, we agree this gives the same performance as a static PF with the miniumun set the same. The only difference is:
it has room to grow if needed.
which is when you will fragment the PF.

However this will NOT affect performance when paging to and from the pagingfile.
The down sides to a fragmented PF are fairly commonly accepted, it's not *that* special. You will need to show us that fragmented PF behaves differently then any other fragmented file. In one breath you question how we determine the PF size, the assume you know what it needs ot be set at to determine the minimum. How do you know what to set at the minimum? What's your method?

Also what do you mean by degraded performance? Do you mean defrageded performance when paging? If you do you are wrong. The pagefile is not read ina seqentual manner so a fragmented pagefile will have NO affect on the performance of paging.
Yes, he means less performnace when it's being read. You do know I/O is limited, and causes strain on the whole system. It doesn't matter if the *whole* PF is read. If 200MB is spun from RAM to PF, that's going to affect performance writting that 200MB of data. So now magically when 200MB is written to the HDD that doesn't affect performance of the system? Write a 200MB file while gaming and tell me that again. Also try to load a new level when that 200MB file is writting. The HDD will be so busy with the PF request it won't even start your request for data until paging is finsihed since it's operating at a higher system priority.

Also since the pagefile is not the only file involved with paging
That's irrelevant to the page file. It's relevant to paging, which is part of VMM. You obviously confuse the three a LOT, which is understandable given the available reading.

VMM is the whole memory management system. Page file is *one* of the files used in paging. Paging is the operation of moving pages of data. Where depends on the specific operation. Virtual memory (again a part of VMM) and paging are not disabled when you remove the PF. You are forcing paging to occur only in RAM, which if you have enough, is the fastest place for it.

You have to remember why the PF was created in the first place. To supplement RAM. Older machines (NT4 era) didn't have enough RAM to load the OS much less apps. That data had to be stored somewhere, and the HDD was the only available place.
 
which is when you will fragment the PF.

Check my post in the sticky.

The down sides to a fragmented PF are fairly commonly accepted, it's not *that* special. You will need to show us that fragmented PF behaves differently then any other fragmented file. In one breath you question how we determine the PF size, the assume you know what it needs ot be set at to determine the minimum. How do you know what to set at the minimum? What's your method?

I reccomend letting Windows manage the pagefile. If you do not want to do this then it is good to set the default high enough that windows does not need to resize the PF. However you should know that the Pf usage graph in the Task mager is not correct as I told you in the sticky. So to see actual pagefile usage you will need to use this or this. I am pretty sure those tell you exactly how much of the pagefile is being used.

Yes, he means less performnace when it's being read. You do know I/O is limited, and causes strain on the whole system. It doesn't matter if the *whole* PF is read. If 200MB is spun from RAM to PF, that's going to affect performance writting that 200MB of data. So now magically when 200MB is written to the HDD that doesn't affect performance of the system? Write a 200MB file while gaming and tell me that again. Also try to load a new level when that 200MB file is writting. The HDD will be so busy with the PF request it won't even start your request for data until paging is finsihed since it's operating at a higher system priority.

It is abvious you do not understand how the pagefile works. Even if the pagefile does get fragmented it will have no affect on paging performance involved with the pagefile because pagefile slots are memory page sized (4K on 32-bit systems) and NT will only do pagefile read-ahead up to 64K at a time.

That's irrelevant to the page file. It's relevant to paging, which is part of VMM. You obviously confuse the three a LOT, which is understandable given the available reading.

How am I confusing them. You are the one who seems to think RAM+PF=VM which tells me you do not even know the basi idea behind Virtual memory.

You are forcing paging to occur only in RAM, which if you have enough, is the fastest place for it.

I already told you the pagefils is NOT the only file involved with paging. If you have no pagefile the paging would occur from exe's and dll's used by the system. Disabling the pagefile will NOT decrease paging activity at all.
 
If your using XP, and your pagefile is disabled, all paging is done into the hardware RAM. This has been confirmed on here many times by a known Microsoft software developer.

Also, a fragmented pagefile can lead to decreased performance. Virtual memory is used like hardware RAM...the files needed to be paged are dumped there. And if you knew how a hard drive works, you'd know it has to span these files across several segments if the pagefile is fragmented. This leads to the HDD head having to scan several areas around the hard drive looking to piece together one single file. Hence, loss of performance.
 
If your using XP, and your pagefile is disabled, all paging is done into the hardware RAM. This has been confirmed on here many times by a known Microsoft software developer.

I already said the pagefile is NOT the only file involved with paging. How many times do I have to say it until you understand? Every exe and dll your system is using is basically a pagefile. Also not to mention in many cases Windows will create a small (~20M) pagefiel on it's own without you knowing.

Also, a fragmented pagefile can lead to decreased performance. Virtual memory is used like hardware RAM...the files needed to be paged are dumped there. And if you knew how a hard drive works, you'd know it has to span these files across several segments if the pagefile is fragmented. This leads to the HDD head having to scan several areas around the hard drive looking to piece together one single file. Hence, loss of performance.

By that reply I can tell you do not even know the basic idea behind Virtual memory. The files are not dumped in Virtual Memory. Virtual memory is completely different then the pagefile :rolleyes:

I also know how a harddrive works and know how Virtual memory and the pagefile works you however do not even know the basics of Virtual Memory. Go read some of the links I posted in the sticky before trying to argue with me.
 
Your mentioning all the time that the pagefile is not the only file involved in paging. Despite the fast Microsoft says otherwise, would you care to list these others files, or will you continue to just spout stuff out without any meat attached? Your credibility is sinking.

Now, before you put your foot in your mouth again, please read this article from Microsoft. Specifically, the paragraph about how you keep the pagefile unfragmented for performance. They also mention virtual memory and pagefile are the same, based on their writing in other articles and this one. They also mention in similar articles to keep the pagefile a static size.

http://support.microsoft.com/default.aspx?scid=kb;en-us;314482

Are you really going to continue to argue with Microsoft themselves? Seriously...don't you think they would know since they, oh I dunno....wrote XP? These documents have been read many times buy myself and Phoenix86. How much long will you continue the game of arguing with the developers of the software in question?

All you have to do is go to Microsoft Support. Then to the Windows XP area and start searching for virtual memory and pagefile. You'll see the facts laid out before you, proving you wrong. It's also from the most credible source in this issue.
 
Your mentioning all the time that the pagefile is not the only file involved in paging. Despite the fast Microsoft says otherwise, would you care to list these others files, or will you continue to just spout stuff out without any meat attached? Your credibility is sinking.

I already mentioned that too. Files such as exe's and dll's are also involved with paging and I know this for a fact. Pick up any book explaining the internal of the OS such as "Windows Internals"

Now, before you put your foot in your mouth again, please read this article from Microsoft. Specifically, the paragraph about how you keep the pagefile unfragmented for performance. They also mention virtual memory and pagefile are the same, based on their writing in other articles and this one. They also mention in similar articles to keep the pagefile a static size.

Didn't I already say that MS uses the term Virtual Memory wrong in Windows? This is why it is in their article. Read any book on the internals of the OS and you will know that MS uses the term VM wrong. It may be hard to believe, but it is true.

If you want to know more read this thread
http://forums.anandtech.com/message...1500375&STARTPAGE=1&FTVAR_FORUMVIEWTMP=Linear

Before you even reply back to me on this read that thread. I think you only need to read the first couple pages as the rest of it is the other guy being an idiot.

The guy who original posted was basically giving me the same argument you were giving me and that is expected since MS does use the term VM incorrectly in their UI and many articles. If you would read some MSDN articles, check outt he links I posted in the sticky or even check out the books I mentioned you would know you are completely wrong.

EDIT: Also read this:
http://aumha.org/win5/a/xpvm.php

That is probally one of the best descriptions I have read. He however have some terms wrong (paged pool is not what he thinks it is, for example) but it's among the best I've seen.
 
Back
Top