DIsabling swap file with 4GB ram. Wise?
- Thread starter TigerUK
- Start date
http://support.microsoft.com/kb/315270
Windows will create a page file that is of a suitable size to service the requirements of kernel device drivers that require paged pool memory allocations.
Windows will create a page file that is of a suitable size to service the requirements of kernel device drivers that require paged pool memory allocations.
Well, not quite. Because a page file whose size is of perhaps 16MB purely to satisfy some esoteric kernel device drivers is hardly going to be of much use to user-mode applications. Especially if those kernel device drivers have already block-allocated what they wanted in the first place. There will be nothing left for user-mode applications.
Does this >252day uptime Vista workstation really look like it is behaving in the way you describe? No, it does not.
was a generalisation...
No, paged kernel memory is often misunderstood. It means that the memory can be moved to the page file, if the memory manager feels it is necessary (if you have a page file).
If a driver allocates from the non-paged pool then memory will never be moved to the page file.
It actually doesn't tell you how muh data Windows has moved to the page file.
Last edited:
So basically it doesn't have any impact at all, as we've seen people disable it and seen no negative implications, and we've heard from people who enable it and have seen no negative implications.
Anyone else think the pagefile is just a placebo? lol
Anyone else think the pagefile is just a placebo? lol
Soldato
- Joined
- 5 Jun 2003
- Posts
- 8,732
- Location
- sawley/ long eaton
just leave it to windows
You are incapable of reading threads.
Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
Those images are an indication of paged and nonpaged pool being exhausted, as highlighted in Mark Russinovich's Pushing the Limits of Windows: Paged and Nonpaged Pool article. May I ask what that has to do with the paging file?
I am certainly not suggesting others to go ahead and disable the paging file because it's useless. In fact, I am doing the opposite (or trying too anyway) and would recommend having a paging file and highlighting the benefits of one. I just don't agree with the scaremongering surrounding the subject.
The paging file has an impact on the system in a various of ways. The most important being related to the system commit limit. The commit limit is the sum of most of physical memory plus the size of the paging file(s). When processes allocate certain types of virtual memory, the allocation gets counted against the commit limit. Windows is making you a commitment that it will be able to back that data by physical memory, or store it on disk in the paging file.
Whether or not a paging file is required is going to depend on the amount of system commit the workload requires in relation to the physical memory capacity of the machine. If for instance the machine which you're using has 6GB of physical memory and the workload which you're running requires 7GB of system commit, you would need a paging file of at least 1GB to support it. If the paging file is any smaller than that, you will hit the system commit limit.
(The above is in a best case scenario)
If the amount of physical memory of the machine exceeds your workloads system commit requirements, you don't need a paging file and Windows will run perfectly fine without one under those circumstances. For example, you have a machine which has 8GB of physical memory and your workload requires 5.5GB of system commit. However, there are a couple of disadvantages with having no paging file.
- The subset of pages on the modified page list which could get written out to the paging file will no longer be able too. This results in less memory being available for other purposes.
- The system won't be able to generate crash dumps. This will also apply to cases whereby you have one, but it isn't large enough to support the crash dump you are configured for.
Last edited:
Everything. With no page file you'll eventually throw a workload at your PC and just run into your system's memory limit without any warning.
Those dialogs and UI glitches are what happens when the system has exhausted all available memory.
I wasn't scaremongering. I was being totally serious. A page file acts as a natural performance inhibitor when memory is low, and as such it prevents you running into the systems total memory limit by total surprise.
Last edited:
Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
I'm sorry but just so I am clear, you're referring to physical memory right? From a technical perspective, how does a paging file help in those circumstances? I'm trying to understand how the paging file has an impact on the system in such a way that having one alerts the user they're running low on memory, assuming you're referring to physical memory, of course.
Page faults.
In order to fulfil the total memory commit size (RAM + page file) the kernel must perform page faults. Which is where a page must be swapped in from the page file. These inherently slow the system down.
If you've got 8GB RAM and a 8GB page file. Then you've got 8GB of safety margin whereby the system will be performing page faults more and more frequently.
In order to fulfil the total memory commit size (RAM + page file) the kernel must perform page faults. Which is where a page must be swapped in from the page file. These inherently slow the system down.
If you've got 8GB RAM and a 8GB page file. Then you've got 8GB of safety margin whereby the system will be performing page faults more and more frequently.
Soldato
- Joined
- 31 May 2009
- Posts
- 21,468
Those sneaky folks who authored the operating system.
Trim the size, don't kill it completely.
Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
Disabling the paging file doesn't eliminate hard page faults though. It just prevents the scenario whereby anything which is backed by the paging file is possibly written and read back in from disk.
A process merely allocating system committed virtual memory will only be impacting system commit. It is only when the process touches the allocation does it demand it to be backed by physical memory.
Assuming you have enough physical memory to support your workloads system commit, Windows will run perfectly fine with no paging file. It isn't a requirement.
Mark Russinovich said:
Last edited:
Disabling the page file would eliminate all page faults relating to pages that exist in the page file, but not in memory (RAM). Because having no page file forces all pages to exist in memory at all times. Even pages that have been idle for weeks or months would still remain in RAM. That's why having no page file is massively wasteful of the precious resource that is RAM. All that the idiots that do it care about is stopping their HDD activity LED from flashing when they don't think it should be.
Memory-mapped files could still generate hard page faults as these aren't in anyway linked to the page file, but they are directly related to the concept of virtual memory and paging. MM files though aren't really seen as a system-wide performance issue. It is simply a different form of file I/O that is useful in certain software designs.
I don't think you fully grok this subject.
Last edited:
Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
Yep, it would eliminate hard page faults from anything which is backed by the paging file. Things like exe's and dll's will still need to be read into memory from disk and therefore causing hard page faults. What I am trying to understand is how does a paging file give a 'visible human cue' to the user they're running low on physical memory, given the fact that hard page faults will occur regardless of whether there is a paging file or not.
I agree, which is one of the reason you would want to have a paging file regardless of whether your workload requires one.
If I don't, that is absolutely fine. I am perfectly happy to read and take on board what other people have to say on a subject to gain a much better understanding of what is being discussed. If I have written something which isn't correct, I hope someone which has more knowledge in that area to say that I am wrong and then correct it where they feel it is necessary.
EXE/DLL files are typically loaded by the OS using memory-mapped file I/O, so as to allow sharing between processes.
The hard page fault generated by those don't really compare to what is caused when a system is running low on memory (and there is a page file).
When a system's committed memory exceeds the amount of RAM it has, then by definition it is "overcommitted" on memory. And as this overcommitment gets worse and worse (i.e. usage approaches the commit limit) then you will find that hard page faults (to/from the page file itself) will increase and increase. This is also known as "disk thrashing" or "disk swapping".
The hard page fault generated by those don't really compare to what is caused when a system is running low on memory (and there is a page file).
When a system's committed memory exceeds the amount of RAM it has, then by definition it is "overcommitted" on memory. And as this overcommitment gets worse and worse (i.e. usage approaches the commit limit) then you will find that hard page faults (to/from the page file itself) will increase and increase. This is also known as "disk thrashing" or "disk swapping".
This comes up all the time, rather than debating what it could be set to lets actaully use some tools to define what it needs to be set to for your machine...
Let windows manage your page file for a couple of weeks, then run this command:
This is my usage on my laptop (4gb)
580MB peak usage - could set it to 1GB and still have plenty of space.
Secondly, set up a pagefile on each physical disk and let the OS which to use (this is the most optimal use of pagefile).
Windows will then load balance over each drive depending on the usage of the drive.
The only issue with setting a smaller pagefile than available ram, or not setting a pagefile on the system drive is the ability to create full memory dmps, which I doubt will be of use to many of you.
-
Always have a back up and SSDs have a warranty - 4GB isn't much these days.
Let windows manage your page file for a couple of weeks, then run this command:
Code:
wmic pagefile get caption, currentusage, peakusageThis is my usage on my laptop (4gb)
Code:
C:\Windows\System32>wmic pagefile get caption, currentusage, peakusage
Caption CurrentUsage PeakUsage
C:\pagefile.sys 349 580580MB peak usage - could set it to 1GB and still have plenty of space.
Secondly, set up a pagefile on each physical disk and let the OS which to use (this is the most optimal use of pagefile).
Code:
C:\Users\rich.admin>wmic pagefile get caption, peakusage
Caption PeakUsage
C:\pagefile.sys 502
D:\pagefile.sys 495
E:\pagefile.sys 497Windows will then load balance over each drive depending on the usage of the drive.
The only issue with setting a smaller pagefile than available ram, or not setting a pagefile on the system drive is the ability to create full memory dmps, which I doubt will be of use to many of you.
-
Always have a back up and SSDs have a warranty - 4GB isn't much these days.
Last edited: