Why is my page file being used so much?

[ThatWasFat]

Ok, here is my current situation. I have 1GB of RAM. If I go to the Task manager performance tab, it says

PF Usage, 570MB.

That seems a little high considering two things.

1.) I have 1GB of RAM and I don't see why the PF needs to be used that much.
2.) My Page file is only 348MB max, as it's a RAM drive.

Does windows even try to use my whole GB? I don't understand why my PF gets used so much.


Thanks

 

[MrChad]

Pagefile != Virtual Memory

Please do a search on this topic as it has been discussed 5,783,408,123 times

 

[CTho9305]

http://ctho.ath.cx/tmp/vm.png <-- View->Select Columns...
You can see that Mozilla currently is using ~217MB ram, and 322-217MB of it is paged out. Sorting by the column labelled "Virtual Memory Usage" lets you see if any apps are causing you to have a giant page file.

 

[BZeto]

I have a gig of memory with a 1.8 GB static page file. Currently using 210MB's of it with some programs open.

 

[Nothinman]

You can see that Mozilla currently is using ~217MB ram, and 322-217MB of it is paged out. Sorting by the column labelled "Virtual Memory Usage" lets you see if any apps are causing you to have a giant page file.

No you can't and no it doesn't. VM Usage in task manager doesn't show you how much data from that process is in the pagefile, just how much virtual address that process has been allocated. That VM could be used for physical memory, memory mapped files or lord knows what else.

Does windows even try to use my whole GB? I don't understand why my PF gets used so much.

It does, most likely the majority of it is going to the System Cache since you're not using it for anything else. The confusion you're having is most likely caused by a few things, first MS misuses the term virtual memory all over the place, secondly the memory counters can't give you exactly what you want to know because of the ways virtual memory and shared pages can work and third you most likely don't understand how virtual memory really works (which is partly MS' fault for misusing the terms all over the place).

 

[CTho9305]

Originally posted by: Nothinman

You can see that Mozilla currently is using ~217MB ram, and 322-217MB of it is paged out. Sorting by the column labelled "Virtual Memory Usage" lets you see if any apps are causing you to have a giant page file.

No you can't and no it doesn't. VM Usage in task manager doesn't show you how much data from that process is in the pagefile, just how much virtual address that process has been allocated. That VM could be used for physical memory, memory mapped files or lord knows what else.

You're right, I didn't consider mapped memory. However, physical memory usage should show up in the Mem Usage column (isn't that what that column is?), and anything that isn't mapped or "special" would have to end up paged, wouldn't it?

 

[Phoenix86]

If your never using over 1GB in PF usage, just disable the PF. It will force the system to use only RAM.

I would strongly recommend you give your system a workout and check the commit charge peak in performance to make sure it's not close to your physical RAM total.

YMMV with disabling the PF, it's a very debatable issue, but in my experience it has little negative side effects, esp if your not close to your limit.

 

[Nothinman]

You're right, I didn't consider mapped memory. However, physical memory usage should show up in the Mem Usage column (isn't that what that column is?), and anything that isn't mapped or "special" would have to end up paged, wouldn't it?

I'm not sure how shared memory gets allocated, I would assume it gets charged to all of the processes that have access to it but I could be wrong. And paged memory may or may not be in the pagefile, shared libraries and executables are the best example.

If your never using over 1GB in PF usage, just disable the PF. It will force the system to use only RAM.

It will also force certain things to break.

 

[Phoenix86]

Originally posted by: Nothinman
It will also force certain things to break.

Such as?

 

[Nothinman]

Certain games, especially since they're getting more and more memory hungry. I also believe Photoshop will fail without a pagefile. Generally anything that makes use of anonymous memory mappings, keeps lots of data in memory, etc has a chance to fail because there is no other backing store available. For that reason it's really difficult to disable the pagefile, usually if you try it'll creage a small one (~20M) in the windows directory without telling you.

 

[Phoenix86]

Basically all I run on my home machine is games, games do not have a problem running with no PF. As I said in my first post, if he doesn't use over his RAM in VM requirements. He doesn't need the extra memory from the PF, in respons to your 'high memory usage." PS complains about no PF, but can still be run, just click OK on that message. Even if it couldn't it's an application issue (single app at that), not an OS issue. As far as data in "lots of data memory", there's always data in RAM, it doesn't fail w/o a "backup store." If your RAM is bad, replace it. Otherwise, storing data in RAM is acceptable, that's what it's there for.

Do you have any links to prove what your saying? All kidding aside, I seriously doubt MS put a check box in thier OS that makes it so unstable... There is lots of FUD on this setting.

 

[bsobel]

1.) I have 1GB of RAM and I don't see why the PF needs to be used that much.

Your confusing pagefile reservations with page file usage. The system has to account for the memory your using and reserve the page file portion it will page to incase you wind up paging. Your likely (other than some maintence work) not paging at all.

2.) My Page file is only 348MB max, as it's a RAM drive.

There is no benefit to this, in fact that memory would be much better served as main system memory. Putting paging file into a ram drive is always the wrong thing to do.

Bill

 

[bsobel]

Originally posted by: Nothinman
Certain games, especially since they're getting more and more memory hungry. I also believe Photoshop will fail without a pagefile. Generally anything that makes use of anonymous memory mappings, keeps lots of data in memory, etc has a chance to fail because there is no other backing store available. For that reason it's really difficult to disable the pagefile, usually if you try it'll creage a small one (~20M) in the windows directory without telling you.

The full and mini dumps also require a page file (the small one you see in the windows dir is so you can always create a minidump)

Bill

 

[Phoenix86]

Originally posted by: bsobelThere is no benefit to this, in fact that memory would be much better served as main system memory. Putting paging file into a ram drive is always the wrong thing to do.

Bill

I TOTALLY agree here. Creating a RAM drive and putting your PF there is worse than just removing the PF. It's keeping the data in the same place(RAM), but with a RAMDrive you have the overhead of the RAMDrive added to the mix.

This is basicaly the same thing as having no PF, just a convoluted way of doing it.

 

[Nothinman]

The full and mini dumps also require a page file (the small one you see in the windows dir is so you can always create a minidump)

Oh yea, I forgot about that.

This is basicaly the same thing as having no PF, just a convoluted way of doing it.

No, it's worse because you've increased memory pressure by removing, in this case, 384M of memory from system use and put a file on there that will probably wouldn't have gotten used at all had you not taken away that chunk of memory.

PS complains about no PF, but can still be run, just click OK on that message.

And what happens when you do run out of memory but have no pagefile around? PS get killed to free memory and you lose all of your work.

As far as data in "lots of data memory", there's always data in RAM, it doesn't fail w/o a "backup store.

I know there's always data in memory, what I mean is that an app that has lots of non-program and non mmaped data, like probably Photoshop after you've made a number of edits to an image. Things like executables, shared libraries and other memory mapped files don't count because they get paged in and out from the orginal files on disk.

If your RAM is bad, replace it. Otherwise, storing data in RAM is acceptable, that's what it's there for.

That's irrelevant, Windows uses the pagefile as a backing store so it has somewhere to page out data in case memory become tight.

 

[Phoenix86]

And what happens when you do run out of memory but have no pagefile around? PS get killed to free memory and you lose all of your work.

I'm not retying this again, read what I wrote.
"If your never using over 1GB in PF usage, just disable the PF. It will force the system to use only RAM.
I would strongly recommend you give your system a workout and check the commit charge peak in performance to make sure it's not close to your physical RAM total." and "He doesn't need the extra memory from the PF, in respons to your 'high memory usage."
In this case, he doesn't need the memory, and your playing a moving target. My first statement says to size his requirements, and if he's under, he could disable the PF. FUD.

Minidump, that is true. I did say " it has little negative side effects" That is one. However, this will NOT cause BSOD, just make troubleshooting them harder. Besides, how many people troubleshoot minidumps on a workstation? Chances are, if things are that bad, just reload. It's not a server afterall...

I know there's always data in memory, what I mean is that an app that has lots of non-program and non mmaped data, like probably Photoshop after you've made a number of edits to an image. Things like executables, shared libraries and other memory mapped files don't count because they get paged in and out from the orginal files on disk.

Got a link to show that no PF causes problem with this?

That's irrelevant, Windows uses the pagefile as a backing store so it has somewhere to page out data in case memory become tight.

I only advocated this because he has plenty of RAM, meaning memory won't be tight. I have also run no PF on a machine that DID reach the end of the RAM, and produced the dreaded "not enough memory available" error, so I closed an app and went about my merry way. Eventually this happen enough I had to enable a PF, however, while it wasn't enabled, an out of memory error was the worse thing I encountered. This is also the same argument as above about not having enough RAM to disable the PF, and again a moving target. FUD.

Seriously, have you ever tried this setting yourself? I'm not saying it's going to increase your FPS by 100%, or make you boot in 7.7 seconds, but it ISN'T going to make your system unstable (again, as long as you have enough RAM).

 

[Nothinman]

My first statement says to size his requirements, and if he's under, he could disable the PF. FUD.

Running without a pagefile is like tightrope walking without a safety net, sure as long as you stay on the ropes you'll be fine but the one time you slip you'll wish you had that net.

Chances are, if things are that bad, just reload. It's not a server afterall...

And how many times do you go through the reload process before you track down the real problem?

Got a link to show that no PF causes problem with this?

Of course not because MS's docs aren't that thorough, but if you understood how VM works it would make sense to you.

Eventually this happen enough I had to enable a PF, however, while it wasn't enabled, an out of memory error was the worse thing I encountered. This is also the same argument as above about not having enough RAM to disable the PF, and again a moving target. FUD.

And what happens when the process that needs more memory is winlogon.exe and it gets killed? You can't guarantee what process will be the one to be starved.

 

[Phoenix86]

There's more intellectual fallacies in you posts than I care to deal with. Moving targets, ad homs., proofless claims. ALL FUD.

If you want to prove this setting is bad show so evidence or quit posting. It's an OS SUPPORTED SETTING, not some registry hack job. But of course, I'm sure MS doesn't understand VM either. :roll:

 

[MrChad]

Originally posted by: Phoenix86
There's more intellectual fallacies in you posts than I care to deal with. Moving targets, ad homs., proofless claims. ALL FUD.

If you want to prove this setting is bad show so evidence or quit posting. It's an OS SUPPORTED SETTING, not some registry hack job. But of course, I'm sure MS doesn't understand VM either. :roll:

Phoenix, you've made some good posts here so far, but this is not one of your better ones. As I suggested to the original poster, please do a search on this topic and read what has been discussed. Nothinman has an excellent understanding of the pagefile system and how it works, and his statements have been validated by Microsoft employees on this board.

EDIT: This thread is a good start. Sianath and kylef are MS employees.

 

[Phoenix86]

I'll give that thread a read. In the meantime, you guys can have have a read too. I did a writeup on sizing PFs for the that forum recently. It's mostly how to size a PF, but discusses when and why no PF is valid.

edit: Hit post too soon, added the rest to make sense.

 

[Phoenix86]

What I'm reading in that thread so confirms what I'm saying, esp if you follow my link. I was trying to get as much of that out w/o linking to that thread (site was down earlier today). BTW my statements in my link have gone though peer validation as well, some from MS.

MrChad, what is incorrect about my statements, or what made it "not a better one?"

Nothinman, I have a fair understanding of VMM, and PFs. You, however, know nothing about me, so let's not assume anything, OK? Can we have a fruitful discussion, or not?

 

[Nothinman]

Nothinman, I have a fair understanding of VMM, and PFs.

Well the fact that your linked post starts with "Virtual Memory (VM) size=RAM+PF" tells me that you have some misunderstandings about even the basic ideas behind VM.

If you require a PF, you should set the minimum and maximum size to the same value

This is also not a good idea because it removes a portion of the safety net provided by the pagefile. If you run out of pagefile space and you set the max too low then you'll just get more OOM problems, but if you let it grow you'll be able to continue with no interruption. And fragmentation hardly affects pagefile performance because pagefile slots are memory page sized (4K on 32-bit systems) and I believe NT will only do pagefile read-ahead up to 64K at a time.

If new data is loaded, the system with a PF would be paging memory to disk, one without will not

This is also wrong, NT will only put data into the pagefile when necessary or if the data hasn't been touched in so long that it feels the memory could be better used by system cache. The PF Usage counter in taskmgr is generally high because it counts reservations as well as used pagefile slots.

This means paging will still happen, it just won't be transferred to the HDD.

The very definition of paging is the reading and writing of page sized chunks of data to and from other media. Normally this is the hard disk, but it also applies to CDs, tapes, etc.

If the secondary drive is slower, it's better to keep it on the same drive as the OS.

This is debatable, because as I said pagefile access happens in very small requests so seek times determine how fast or slow the access will be. If the slower drive isn't doing anything else seek times will still be low unless the drive is really old. And if you have enough memory it won't matter anyway because there will be virtually no pagefile access.

As noted by Ranma_Sao, you cannot obtain a full memory dump if your page file is less that your total RAM.

Full memory dumps are generally useless, all you really need is a mini-dump which includes the kernel memory.

 

[Phoenix86]

Well the fact that your linked post starts with "Virtual Memory (VM) size=RAM+PF" tells me that you have some misunderstandings about even the basic ideas behind VM.

OK, I'll bite... what? Perhaps I misused a term? I'm aware of other VM files for things like system cache, but those are seperate files from the PF.

This is also not a good idea because it removes a portion of the safety net provided by the pagefile. If you run out of pagefile space and you set the max too low then you'll just get more OOM problems, but if you let it grow you'll be able to continue with no interruption. And fragmentation hardly affects pagefile performance because pagefile slots are memory page sized (4K on 32-bit systems) and I believe NT will only do pagefile read-ahead up to 64K at a time.

I understand the "safety net" of running out of PF space. However, in the writeup, I'm tell you to sized you memory requirements, and unless that changes, you won't. The whole point of the article is to learn how to size it. If you screw that up, yes, you will have problems with the values you set, like running out of memory.

This is also wrong, NT will only put data into the pagefile when necessary or if the data hasn't been touched in so long that it feels the memory could be better used by system cache. The PF Usage counter in taskmgr is generally high because it counts reservations as well as used pagefile slots.

How can this be wrong? Are you saying the PF will still exist and the system will use it even though no PF has been setup? The full quote is: "the system does not need the extra memory from the PF for VM. There is enough RAM to supply all the VM needs. If new data is loaded, the system with a PF would be paging memory to disk, one without will not." I'm simply stating that a no PF system doesn't use pagefile.sys.

How is that wrong?

The very definition of paging is the reading and writing of page sized chunks of data to and from other media. Normally this is the hard disk, but it also applies to CDs, tapes, etc.

Yes, I pretty much agree. How is this relevant? I'm stating that by disabling the PF, your not disabling paging. It still happens, though w/o a PF, data is paged to RAM (since the PF doesn't exist).

This is debatable, because as I said pagefile access happens in very small requests so seek times determine how fast or slow the access will be. If the slower drive isn't doing anything else seek times will still be low unless the drive is really old. And if you have enough memory it won't matter anyway because there will be virtually no pagefile access.

I agree, the location of a PF can vary widely from system to system.. I tried to avoid this topic, as it's very different from sizing the PF.

Full memory dumps are generally useless, all you really need is a mini-dump which includes the kernel memory.

That poster works at MS, and analyzes full dumps for others. I don't know what the difference is from a full and mini dump in regards to how much gives what information. I think MS needs to dump the data into it's own file seperate from the PF anyways, akin to the hiberfile.sys. Best of both worlds there...

EDIT: thanks for taking the time to look at it.

 

[stash]

OK, I'll bite... what? Perhaps I misused a term? I'm aware of other VM files for things like system cache, but those are seperate files from the PF.

Virtual memory is not a file, it's an abstraction. Hence the word 'virtual'. It is not RAM+PF. VM is the address space available to any process on a system. On a 32-bit system, the VM will always be 4 GB.

In Windows, this space is split between user and kernel mode processes, each having 2 GB available (by default).

 

[Nothinman]

I understand the "safety net" of running out of PF space. However, in the writeup, I'm tell you to sized you memory requirements, and unless that changes, you won't. The whole point of the article is to learn how to size it. If you screw that up, yes, you will have problems with the values you set, like running out of memory.

But the fact remains that unless you never install any updates or new software you can't be sure that the sizes you picked will remain constant and the cost of leaving the pagefile growable is virtually nothing.

How is that wrong?

In many situations even if you set the pagefile to 0 the system will create a small (~20M) pagefile on the system drive because XP knows that it's necessary in some cases and having one is safer.

Yes, I pretty much agree. How is this relevant? I'm stating that by disabling the PF, your not disabling paging. It still happens, though w/o a PF, data is paged to RAM (since the PF doesn't exist).

Data is always paged to physical memory whether you have a pagefile or not, removing the pagefile should not decrease the amount of paging on a system at all. Well unless you cause things to die because there's not enough memory to handle something and there's no pagefile to free some of memory.

That poster works at MS, and analyzes full dumps for others. I don't know what the difference is from a full and mini dump in regards to how much gives what information. I think MS needs to dump the data into it's own file seperate from the PF anyways, akin to the hiberfile.sys. Best of both worlds there...

A memory dump from a BSOD is stored in the pagefile and then copied to a seperate dump file, if you want a full dump you need a pagefile the size of physical memory + some extra (20M IIRC) but if you want a kernel dump you only need like 12M. The only thing a full dump will give you is all of the data on running processes, it's possible one of them is causing the BSOD but not likely and you can usually identify the driver at fault from just a minidump.

And the hiberfil.sys file is irrelevant, it stores system state so that it can be resumed from later and it has to be the size of physical memory because there's a chance that you would try to hibernate the system when memory is 100% full and part of the pagefile is used and unless your pagefile is 2 or 3 times as big as your physical memory the chances are slim that you'll have enough space in the pagefile to hold the memory state and the current data in the pagefile.