![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Paging file
- Thread starter dmonkey
- Start date
It is highly, highly, strongly, strongly recommended that you do not disable paging, even if you have many gigs of RAM.
If you must, you do the following:
1. Use Control Panel to open the System applet.
2. Select the Advanced tab.
3. Press the Settings button in the Performance section.
4. Select the Advanced tab.
5. Press Change in the Virtual Memory section.
6. Select the No paging file radial button and press Set.
7. Press OK.
If you must, you do the following:
1. Use Control Panel to open the System applet.
2. Select the Advanced tab.
3. Press the Settings button in the Performance section.
4. Select the Advanced tab.
5. Press Change in the Virtual Memory section.
6. Select the No paging file radial button and press Set.
7. Press OK.
This is very debatable as wether it will help performance or not. However it won't really hurt stability much either... There are some good arguments for and against disabling the PF. Before a flame fest ensues, I'd strongly suggest you search the OS subforum a bit to see past discussions on this topic.
ThomasEE, you too... While I'm pressed to say "disabling the PF will yield grand performance boosts" I can't say "I'd recommend against is because your system will be unstable." Fact is I have run sans-PF on several machines for quite a while and seen no downside in the form of errors or crashes. What I do see is my machine page like crazy when I near my RAM total (OS is paging to make more free RAM) when it isn't quite necessary. Should I disable the PF on the machine I'm typing on it'll not page when I near my RAM total (and on this P-III-600 laptop you can really feel paging), however sometimes I do exceed my RAM total in used system memory, so I require a PF.
Anyways, there are several threads about the benefits/costs.
dmonkey, what OS are you running? Do you still see a PF after doing ThomasEEs steps?
edit: just read your reply, what OS is this?
ThomasEE, you too... While I'm pressed to say "disabling the PF will yield grand performance boosts" I can't say "I'd recommend against is because your system will be unstable." Fact is I have run sans-PF on several machines for quite a while and seen no downside in the form of errors or crashes. What I do see is my machine page like crazy when I near my RAM total (OS is paging to make more free RAM) when it isn't quite necessary. Should I disable the PF on the machine I'm typing on it'll not page when I near my RAM total (and on this P-III-600 laptop you can really feel paging), however sometimes I do exceed my RAM total in used system memory, so I require a PF.
Anyways, there are several threads about the benefits/costs.
dmonkey, what OS are you running? Do you still see a PF after doing ThomasEEs steps?
edit: just read your reply, what OS is this?
I didn't say it would make the system unstable 
Microsoft highly recommends you do not turn paging off. I have seen a few problems relating to it in my time, but not many.
A good compromise is to disable paging of the kernel. That way the OS itself never gets swapped out to disk.
Microsoft highly recommends you do not turn paging off. I have seen a few problems relating to it in my time, but not many.A good compromise is to disable paging of the kernel. That way the OS itself never gets swapped out to disk.
Phoenix86 said:I was just going off your first sentence. Lots of FUD out there about that setting and what it does and doesn't do...
Agreed. Basically, there is no reason to turn off paging. If you have that much RAM that you think you don't need a pagefile, then eliminating paging won't buy any performance.
I posted in another thread recently about this, and while I can't locate the exact thread at this moment, you can just search for recent postings from me if you are so inclined.
In a nutshell, here's the simple in-your-face truth that you are going to have to deal with:
You cannot disable the pagefile on a Windows NT4/2K/XP/2K3 machine permanently.
It's simply not possible to do it. Windows will create a pagefile for itself no matter what you do, no matter how much RAM you have, no matter how bad your boxen is.
Windows always uses virtual memory for every program you use. Simple.
Don't believe me?
Here's the short version to prove it:
Open Task Manager. Click the Processes tab. Those are all the running processes that you have functioning. With Task Manager still open, click View, then click Select columns...
You can uncheck User Name because no one really uses that anyway, but you need to put a check in these two boxes:
Peak Memory Usage
Virtual Memory Usage
Now, click OK and voila, you now get to see CPU Usage, Memory Usage (actual RAM being used), Peak Memory Usage (the measure of the peak physical RAM usage since the application/process was initiated), and the most important column:
The VM (Virtual Memory) Size of pagefile space currently in use by Windows itself.
Go turn off your pagefile, completely disable it. Reboot.
When you come back, open Task Manager again and look at it. Guess what, the VM Size column is still there and it will show you the Virtual Memory that Windows is creating on the hard drive for all the apps currently active.
You can't get rid of virtual memory in Windows. Anything you do to try and improve on Windows' management of the virtual memory/pagefile - other than hard setting a specific size - is detrimental in almost all respects and will hurt performance rather than improve it.
Hope this helps...
Paul
In a nutshell, here's the simple in-your-face truth that you are going to have to deal with:
You cannot disable the pagefile on a Windows NT4/2K/XP/2K3 machine permanently.
It's simply not possible to do it. Windows will create a pagefile for itself no matter what you do, no matter how much RAM you have, no matter how bad your boxen is.
Windows always uses virtual memory for every program you use. Simple.
Don't believe me?
Here's the short version to prove it:
Open Task Manager. Click the Processes tab. Those are all the running processes that you have functioning. With Task Manager still open, click View, then click Select columns...
You can uncheck User Name because no one really uses that anyway, but you need to put a check in these two boxes:
Peak Memory Usage
Virtual Memory Usage
Now, click OK and voila, you now get to see CPU Usage, Memory Usage (actual RAM being used), Peak Memory Usage (the measure of the peak physical RAM usage since the application/process was initiated), and the most important column:
The VM (Virtual Memory) Size of pagefile space currently in use by Windows itself.
Go turn off your pagefile, completely disable it. Reboot.
When you come back, open Task Manager again and look at it. Guess what, the VM Size column is still there and it will show you the Virtual Memory that Windows is creating on the hard drive for all the apps currently active.
You can't get rid of virtual memory in Windows. Anything you do to try and improve on Windows' management of the virtual memory/pagefile - other than hard setting a specific size - is detrimental in almost all respects and will hurt performance rather than improve it.
Hope this helps...
Paul
I have found that out for myself, I had already done the proper steps to disable the pagefile before ThomasE66 gave me the instructions. It just seems like Windows XP Pro pages no matter what you set it too.
I was looking for an solution for my Counterstrike problem, albeit with too much hope.
I was looking for an solution for my Counterstrike problem, albeit with too much hope.
Commit charge / the "mem usage" graph in Win2K / the "PF usage" graph in XP: This is not "total memory" in any way shape or form. It is virtual memory, but only a portion of the virtual memory. It is the sum of all the processes' "VM size" from the processes tab, plus some systemwide stuff like the paged pool (which shows up on the performance tab) and some other system wide stuff (that doesn't show up on the performance tab).
But this is only a part of the total virtual memory allocated by all the processes. i.e. the "VM size" label on the processes tab is misleading. This is simply process-private, writeable virtual address space. It's what the Performance applet calls "Private bytes" for each process, and system-wide calls "Committed bytes".
The sum of the actual pagefile usage, plus the physical memory used to realize such virtual address space, is what shows up as "committ charge". You can think of this figure as the maximum potential pagefile usage: If somehow everything in RAM had to be dropped to make room for other stuff, this is how much pagefile space would be needed. Some of it will usually already be in the pagefile at any given moment.
If you want to know the current actual pagefile usage, get the current pagefile size from either explorer or the system control panel applet, then look at the "%usage" counter under the Pagefile object in the Performance applet, and multiply.
So what you are seeing in the Task manager is NOT pagefile usage, oddly enough. Also all disabling the pagefile will do is decrease performance in the long run. Just leave it System Managed.
Also br0adband. You are confused. Virtual Memory is not the same as the pagefile. You are correct that you cannot disable virtual memory though. Also I have heard Windows will sometimes make a small 20MB pagefile in the system32 directory when one is not found, but I am not sure if this is true.
You cannot disable paging. By disabling the pagefile all you are doing is forcing all paging to be done to pages containing code and mapped files. This will in the long run cripple the file cache and slows down code execution
But this is only a part of the total virtual memory allocated by all the processes. i.e. the "VM size" label on the processes tab is misleading. This is simply process-private, writeable virtual address space. It's what the Performance applet calls "Private bytes" for each process, and system-wide calls "Committed bytes".
The sum of the actual pagefile usage, plus the physical memory used to realize such virtual address space, is what shows up as "committ charge". You can think of this figure as the maximum potential pagefile usage: If somehow everything in RAM had to be dropped to make room for other stuff, this is how much pagefile space would be needed. Some of it will usually already be in the pagefile at any given moment.
If you want to know the current actual pagefile usage, get the current pagefile size from either explorer or the system control panel applet, then look at the "%usage" counter under the Pagefile object in the Performance applet, and multiply.
So what you are seeing in the Task manager is NOT pagefile usage, oddly enough. Also all disabling the pagefile will do is decrease performance in the long run. Just leave it System Managed.
Also br0adband. You are confused. Virtual Memory is not the same as the pagefile. You are correct that you cannot disable virtual memory though. Also I have heard Windows will sometimes make a small 20MB pagefile in the system32 directory when one is not found, but I am not sure if this is true.
You cannot disable paging. By disabling the pagefile all you are doing is forcing all paging to be done to pages containing code and mapped files. This will in the long run cripple the file cache and slows down code execution
Using Explorer to get the current pagefile size is only valid for people using dynamic pagefiles, and hopefully the tweakhounds know better than to do such a thing since it only hampers performance. A hard set pagefile (same size for minimum and maximum, aka static) is the best solution. Use the 1.5x physical RAM if you have to; not all users need to use so much hard drive space for a pagefile, but some do.
I know Virtual Memory isn't the pagefile; the pagefile is a component of the Virtual Memory subsystem of Windows. It's the physical component of it since it's "memory mapped to a physical/mechanical device" and not solid-state as the physical RAM is. That means it's much much slower as we all know.
It's true, as I stated. Windows will always create a pagefile on the hard drive for any and all software you use, including the OS itself. Windows is and always has been coded to take advantage of virtual memory extensions of the i386 architecture. Ok, so if Windows 1.0 was running on an i286 you got me, that's before most of you peeps time.
Regardless, it comes down to this:
In light of the fact that the pagefile is a component of Virtual Memory in Windows, and it's always going to be there regardless of your decision to disable it or not, the less you need to hit the pagefile (read: physical hard drive accesses) the faster your PC operates. There are several very basic requirements for setting the pagefile up so that you ensure optimum performance on most (if not all) PCs:
1) Make the pagefile one specific size by setting the minimum size to the same as the maximum size. This helps in two primary ways: (a) it lets Windows take care of the pagefile and not have to resize it dynamically which would just hinder performance even further, and (b) in the process of doing (a) you help reduce the likelihood of the pagefile becoming fragmented all over the place - which is what happens with a dynamically allocated one.
2) Put the pagefile on a completely seperate hard drive on a completely seperate cable/controller if at all possible. Since IDE controllers can't read and write to the Master and Slave channels of the same controller at the same time, putting the pagefile on a second hard drive on the same cable wouldn't help and would actually be detrimental to the performance of the PC. Getting it onto a hard drive on a seperate cable/controller is the key to maximum performance.
An example is this:
Primary Master: system hard drive, the one with Windows on it
Secondary Slave: second hard drive with the static pagefile on it
would be the optimum configuration for a PC with two hard drives not used in conjunction with each other - meaning not used together as a RAID volume.
Most people tend to put CD/DVD drives on the Secondary Master which is just fine although it's not absolutely necessary. You could just as easily make that second hard drive the Secondary Master and things would work just fine.
That pretty much ensures a well running and very quick Virtual Memory subsystem for any PC running Windows. The overwhelming majority of users still have just one hard drive in their PCs, and as such, the only useful tip to help comes in two parts:
-- Get more RAM, as much as you can afford and as much as the system motherboard allows
-- Make a static pagefile, same size for minimum and maximum
Paul
I know Virtual Memory isn't the pagefile; the pagefile is a component of the Virtual Memory subsystem of Windows. It's the physical component of it since it's "memory mapped to a physical/mechanical device" and not solid-state as the physical RAM is. That means it's much much slower as we all know.
It's true, as I stated. Windows will always create a pagefile on the hard drive for any and all software you use, including the OS itself. Windows is and always has been coded to take advantage of virtual memory extensions of the i386 architecture. Ok, so if Windows 1.0 was running on an i286 you got me, that's before most of you peeps time.
Regardless, it comes down to this:
In light of the fact that the pagefile is a component of Virtual Memory in Windows, and it's always going to be there regardless of your decision to disable it or not, the less you need to hit the pagefile (read: physical hard drive accesses) the faster your PC operates. There are several very basic requirements for setting the pagefile up so that you ensure optimum performance on most (if not all) PCs:
1) Make the pagefile one specific size by setting the minimum size to the same as the maximum size. This helps in two primary ways: (a) it lets Windows take care of the pagefile and not have to resize it dynamically which would just hinder performance even further, and (b) in the process of doing (a) you help reduce the likelihood of the pagefile becoming fragmented all over the place - which is what happens with a dynamically allocated one.
2) Put the pagefile on a completely seperate hard drive on a completely seperate cable/controller if at all possible. Since IDE controllers can't read and write to the Master and Slave channels of the same controller at the same time, putting the pagefile on a second hard drive on the same cable wouldn't help and would actually be detrimental to the performance of the PC. Getting it onto a hard drive on a seperate cable/controller is the key to maximum performance.
An example is this:
Primary Master: system hard drive, the one with Windows on it
Secondary Slave: second hard drive with the static pagefile on it
would be the optimum configuration for a PC with two hard drives not used in conjunction with each other - meaning not used together as a RAID volume.
Most people tend to put CD/DVD drives on the Secondary Master which is just fine although it's not absolutely necessary. You could just as easily make that second hard drive the Secondary Master and things would work just fine.
That pretty much ensures a well running and very quick Virtual Memory subsystem for any PC running Windows. The overwhelming majority of users still have just one hard drive in their PCs, and as such, the only useful tip to help comes in two parts:
-- Get more RAM, as much as you can afford and as much as the system motherboard allows
-- Make a static pagefile, same size for minimum and maximum
Paul
Making a static pagefile will just make it so Windows cannot increase the size of the Pf if needed. If set high enough this may not be a problem, but I suggest setting the initial size to about 4x the amount of pagfile being used when running your most memory intensive applications. Then setting the max 2x this. With having a initial size 4x the amount of pagfile being used the pagefile will never have to be resized anyway unless under an extremely heavy load. If under such a load the pagefile can increase in size though.
Also fragmentation of the pagefile will NOT decrease performance related to the pagefile. This is because Windows NEVER reads or writes more than 64 KBytes per buffer to the pagefile. Windows will also almost never reads or writes the pagefile in sequential 64Kbyte chunks. So after reading or writing one such buffer it WILL have to move the heads, no matter how frag'd the pagefile is.
These pagefile IOs will be interspersed with paging IOs to many other files, and non-paging IOs to many other files, too.
In between ALL such IOs the heads will have to move anyway. This is why fragmentation of individual files matters far less than the defrag vendors want you to believe.
The only way a fragmented pagefile will decrease performance is fragmentation of files around the pagefile since it cannot be moved. Again this does not affect performance as MUCH as many people want you to think though.
Also fragmentation of the pagefile will NOT decrease performance related to the pagefile. This is because Windows NEVER reads or writes more than 64 KBytes per buffer to the pagefile. Windows will also almost never reads or writes the pagefile in sequential 64Kbyte chunks. So after reading or writing one such buffer it WILL have to move the heads, no matter how frag'd the pagefile is.
These pagefile IOs will be interspersed with paging IOs to many other files, and non-paging IOs to many other files, too.
In between ALL such IOs the heads will have to move anyway. This is why fragmentation of individual files matters far less than the defrag vendors want you to believe.
The only way a fragmented pagefile will decrease performance is fragmentation of files around the pagefile since it cannot be moved. Again this does not affect performance as MUCH as many people want you to think though.
Your confusing terms.
VM != PF. The PF is a subset of VM, but there's more to it. The amount of commit charge is limited by RAM+PF. Essentially this is the real limit to virtual memory. This is also why much of your "theory" about disabling PF fails. You CAN disable the page file, you CAN'T disable paging. Paging is the process of moving pages of memory, but it doesn't specify where. You can page to RAM as well as page to disk (PF). This is why disabling the PF doesn't disable VM, and thus why you ARE able to disable the PF (XP only, NT and 2K will still create a small PF due to OS restrictions).
Let me ask you this, if "you cannot disable the pagefile on a Windows NT4/2K/XP/2K3 machine permanently", then what is the file name used for paging when the PF is disabled?
While you are correct the pagefile is by far not the only file involved in paging. Every exe and dll are also involved with paging. That is why placement of the pagefile is pretty silly to me.
So as you said disabling the pagefile will NOT disable Virtual memory OR paging. When you disable the pagefile only code and mapped files can be paged out of RAM. If you have any "private" stuff in RAM it will have to stay there even if it has not been touched for ages. So by disabling the pagefile there will be MORE paging of code. There may be specific short-term events that may show and improvement of disabling a pagefile like some have claimed faster loading times in some games, but what they don't know is it is hurting them in the long run.
Here is a good references to back up the concepts:
http://support.microsoft.com/default.aspx?scid=kb;en-us;555223
http://support.microsoft.com/default.aspx?scid=kb;en-us;555223
I know you realize that explaining the entire VMM subsystem would take quite a few pages of text, which is why I said there was more to it.KoolDrew said:
I'm simply correcting is misuse of the terms he's brought up.
rcolbert, that's a damn fine link explaining paging and all that stuff.
My questions is why was it *just* published...? Last Review : December 12, 2004 (also the published date, rev 1.0).Phoenix86 said:that's a damn fine link explaining paging and all that stuff.
That's a valid question. 99% of everything that's come out of Redmond before seems to be a "how to change the size of your pagefile document" or a "here's how the vmalloc() function works."
(In fairness, I've seen at least one other good article but can't seem to find it now.)