Hmm that's a point actually. Mine is configured at default to be a kernel memory dump, not a full memory dump. So the system managed size of the pagefil at 64GB is in effect wasting SSD space and I can just set it to the smallest recommended size which according to Windows is 9072MB. My system never crashes though so tbh even that is a non req for me I guess.
Paging file increase/decrease
- Thread starter Yella Fella
- Start date
True, although task manager shows my commit nowhere near hitting the commit limit:
And that's with Lightroom having been run all day editing large photos, 3 browser windows and multiple tabs etc. So realistically, system managed for me isn't an efficient use of the OS drive space really it would seem. It is not something I have looked back at since this 64GB upgrade from 32GB.
And that's with Lightroom having been run all day editing large photos, 3 browser windows and multiple tabs etc. So realistically, system managed for me isn't an efficient use of the OS drive space really it would seem. It is not something I have looked back at since this 64GB upgrade from 32GB.
Some kind of memory leak, but obviously increasing my pagefile (as mentioned earlier in the thread) merely delayed the issue, rather than solving it
Currently monitoring with poolmon.exe to try and work out what is causing the leak (just a shame the system became unusable before I was able to get poolmon downloaded
)Tracked it down (noticed that DSEASDK.exe had over 11,000 handles) and hopefully it's related to an EPOS headset issue
www.3cx.com
EPOS (Sennheiser) Connect 7.x memory leak
Earlier this year EPOS updated their headset Connect software from 4.x to 7.x. The software has a horrible memory leak in the DSEASDK component. Basically, if one leaves the PC logged in for about 48 hours Windows will run out of virtual memory and crash. The DSEA process does not indicate...
www.3cx.com
I have 32gb of memory and set both the min and max page file as 5gb because then it doesn't mess up the drive, I have a bit of OCD going on..hehe
I would defrag the drive but defragging SSD's doesnt do them much good... The yellow is the page file.
Edit: I think I have figured it out.. Its annoying because when windows crashes, the page file gets deleted for some reason, so windows puts the memory.dmp file where the page file goes, so theres a huge hole where the page file goes as the pagefile is forced at the end of the drive. So I then have to delete the dump file and disable and enable the paging so the page file gets deleted and puts it back in its place again.
I would defrag the drive but defragging SSD's doesnt do them much good... The yellow is the page file.
How do you disable the dump file because its annoying because it puts a 1gb memory.dmp fiile in the widows folder when windows throws its toys out of the pram and crashes?
Edit: I think I have figured it out.. Its annoying because when windows crashes, the page file gets deleted for some reason, so windows puts the memory.dmp file where the page file goes, so theres a huge hole where the page file goes as the pagefile is forced at the end of the drive. So I then have to delete the dump file and disable and enable the paging so the page file gets deleted and puts it back in its place again.
Last edited:
Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
There are three main reasons why you might want to change the size of the paging file.
In terms of sizing the paging file, if the amount of system committed virtual memory exceeds the amount of physical memory you have when you have loaded up your most demanding workload, the "Minimum" will need to be at least the difference between those two values. For example, you have 8GB of RAM and your workload requires 11GB of system committed virtual memory. You will need to set the "Minimum" to at least 3GB. It would be sensible to add an additional amount to that value so you have plenty of breathing room. For the "Maximum" size, there is no reason to set this to the same value as the "Minimum" size. The paging file only expands if there is a demand for it and as long as the "Minimum" is large enough, the paging file will never need to grow. In fact, you could set the "Maximum" to a very large number because it could prove useful in situations where an application is leaking virtual memory.
While I would recommend having a paging file, I feel there is far too much scaremongering around the subject. It has even gotten to the point whereby certain developers have written their applications based on the assumption a page file is necessary. Mark Russinovich himself assured me a page file is absolutely not necessary for Windows to function correctly and any application requiring a paging file to function is based on that misconception. However, none the less if you try and run these applications with no paging file, they will fail to run correctly. This is something to consider.
If you have no paging file, in those instances, pages on the modified page list have no where to be written to and will therefore stay resident in physical memory occupying space. This does not cause any problems. The system will still function absolutely fine in these cases. It will just mean you will have less physical memory available to you.
What if you have enough physical memory to support the system committed virtual memory requirements of the system, you have set up Windows so it doesn't require a crash dump, and you have no applications that unnecessarily require a paging file, why have one? It's to allow the system to use physical memory in the most efficient way possible. What if you have so much "Available" physical memory, letting the modified page list grow isn't going to have much of an impact on the performance of your system. In those circumstances, disabling the paging file isn't going to make any difference to the performance of your system anyway. Everything in your performance interest will already be resident in physical memory.
As Armageus has already pointed out, the Pushing the Limits of Windows Series articles are well worth reading.
Pushing the Limits of Windows: Physical Memory
Pushing the Limits of Windows: Virtual Memory
Pushing the Limits of Windows: Paged and Nonpaged Pool
Pushing the Limits of Windows: Processes and Threads
Pushing the Limits of Windows: Handles
Pushing the Limits of Windows: USER and GDI Objects – Part 1
Pushing the Limits of Windows: USER and GDI Objects – Part 2
- The system commit limit isn't large enough to support the system commited virtual memory requirements of your particular workload.
- The paging file is taking up a significant amount of hard drive space.
- You want to configure the system for a crash dump.
In terms of sizing the paging file, if the amount of system committed virtual memory exceeds the amount of physical memory you have when you have loaded up your most demanding workload, the "Minimum" will need to be at least the difference between those two values. For example, you have 8GB of RAM and your workload requires 11GB of system committed virtual memory. You will need to set the "Minimum" to at least 3GB. It would be sensible to add an additional amount to that value so you have plenty of breathing room. For the "Maximum" size, there is no reason to set this to the same value as the "Minimum" size. The paging file only expands if there is a demand for it and as long as the "Minimum" is large enough, the paging file will never need to grow. In fact, you could set the "Maximum" to a very large number because it could prove useful in situations where an application is leaking virtual memory.
While I would recommend having a paging file, I feel there is far too much scaremongering around the subject. It has even gotten to the point whereby certain developers have written their applications based on the assumption a page file is necessary. Mark Russinovich himself assured me a page file is absolutely not necessary for Windows to function correctly and any application requiring a paging file to function is based on that misconception. However, none the less if you try and run these applications with no paging file, they will fail to run correctly. This is something to consider.
This is going to be a rather simplified version of what is happening but hopefully it will be straight forward enough and illustrate why a paging file is not necessary. When a modified private or page file-backed page is removed from a processes working set, the page will be put onto the modified page list. Those modified pages will eventually be written to disk and then subsequently moved to the standby page list. The modified page list is counted towards the "In use" counter (I believe) in memory statistics. This is why having a paging file is good practice. You want to move those infrequently accessed pages out of processes working sets and onto the standby page list where they can become available for other purposes.Mark Russinovich said:
If you have no paging file, in those instances, pages on the modified page list have no where to be written to and will therefore stay resident in physical memory occupying space. This does not cause any problems. The system will still function absolutely fine in these cases. It will just mean you will have less physical memory available to you.
What if you have enough physical memory to support the system committed virtual memory requirements of the system, you have set up Windows so it doesn't require a crash dump, and you have no applications that unnecessarily require a paging file, why have one? It's to allow the system to use physical memory in the most efficient way possible. What if you have so much "Available" physical memory, letting the modified page list grow isn't going to have much of an impact on the performance of your system. In those circumstances, disabling the paging file isn't going to make any difference to the performance of your system anyway. Everything in your performance interest will already be resident in physical memory.
As Armageus has already pointed out, the Pushing the Limits of Windows Series articles are well worth reading.
Pushing the Limits of Windows: Physical Memory
Pushing the Limits of Windows: Virtual Memory
Pushing the Limits of Windows: Paged and Nonpaged Pool
Pushing the Limits of Windows: Processes and Threads
Pushing the Limits of Windows: Handles
Pushing the Limits of Windows: USER and GDI Objects – Part 1
Pushing the Limits of Windows: USER and GDI Objects – Part 2
Last edited:
This.
16GB should be seen as absolute minimum for anyone using Windows for anything more than light web browsing.
Put a request in for 16 or 32GB.
Not sure there is any advantage to setting 1GB max and some disadvantages if the system ever does need more.
Setting a 1GB minimum seems to change the way the swap system works vs system managed or a higher minimum - in some games for instance setting 1GB minimum means they allocate around 300-500MB while with system managed they can be using around 3GB - from what I can see it is just lazy garbage collection which might have some minor performance benefit on a lower end system but likely makes no real difference on a high spec system.
Setting a 1GB minimum seems to change the way the swap system works vs system managed or a higher minimum - in some games for instance setting 1GB minimum means they allocate around 300-500MB while with system managed they can be using around 3GB - from what I can see it is just lazy garbage collection which might have some minor performance benefit on a lower end system but likely makes no real difference on a high spec system.
Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
Based on my understanding of the subject, the paging file is not something which has an impact on system performance, certainly not in any meaningful way. It simply provides a backing store for certain types of virtual memory that would have to otherwise reside in RAM. The main component of the paging file being the impact it has on the system commit limit, which if it isn't large enough, will cause a whole host of issues. As long as the paging file is large enough to support the system committed virtual memory requirements of the workload being run, there isn't really much more one has to worry about. This is why a lot of people suggest letting Windows manage the size of it. Due to the formula Windows uses to determine the size of the paging file, the system commit limit, in 99% of cases, will always be large enough. Having a paging file also allows the system to use physical memory in the most efficient way possible; by removing the least frequently accessed private pages of memory out to disk.
To answer Yella Fella's original question, if you are using close to all of the 8GB of RAM, the amount of system committed virtual memory allocated will likely be breaching 8GB. Therefore, it makes me question the size of your paging file. As already been suggested though, because you are low on "Available" physical memory, which is such a precious resource, even if you're not experiencing issues related to the system commit limit, you would benefit from more physical memory anyway. Though, of course, I understand simply adding RAM isn't always necessarily a simple thing to do.
Windows Internals 7th Edition - Part 1 said:
To answer Yella Fella's original question, if you are using close to all of the 8GB of RAM, the amount of system committed virtual memory allocated will likely be breaching 8GB. Therefore, it makes me question the size of your paging file. As already been suggested though, because you are low on "Available" physical memory, which is such a precious resource, even if you're not experiencing issues related to the system commit limit, you would benefit from more physical memory anyway. Though, of course, I understand simply adding RAM isn't always necessarily a simple thing to do.
Last edited: