(Mrk, I apologise for responding to your post a little back to front. I thought it would make a little more sense responding to your post in this manner. 
)
For reference, I have 16GB RAM and as you can see, the PF is still required and used by Windows, even if the actual usage is tiny (220MB), it's still a needed thing.
A paging file is beneficial, but it is not a requirement. Windows can run perfectly fine without one. The role of the paging file is so Windows can write a subset of pages on the modified page list out to the paging file. Pages on the modified page list represent pages which have been taken out of a process working set because they haven't been accessed recently but have yet to be written to disk. If you have disabled the paging file, those pages won't be written out to disk, and they will stay on the modified page list. While this will result in less memory being available for other purposes, it's not going to cause any problems.
200MB may not be enough in most cases. On my own machine after 2 days of Lightroom/Photoshop, gaming and media watching as well as constant browser usage my PF is using a max of 220MB of space (now at 165MB), it is manually set to be 2GB min/max.
Monitor your usage using Windows gadgets or the Resource monitor and then manually set a small enough pagefile based on your usage.
Monitoring how much has been written to the paging file and then sizing it accordingly isn't really the correct way of determining how large the paging file needs to be. When it comes to sizing the paging file, the priority should be on how it impacts the system commit limit. When processes allocate certain types of virtual memory, the allocation will get charged against the system 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. The commit limit is therefore the sum of most of physical memory plus the size of the paging file(s). You can monitor how much system commit your workload requires by
Process Explorer. If you open the 'System Information' window, the information will be shown under the 'Commit Charge (K)' section of the 'Memory' tab.
Commit Charge (K):
- Current - This represents the amount of committed virtual memory processes have currently allocated which must be backed by physical memory or stored in the paging file.
- Limit - This represents the amount of committed virtual memory processes can allocate at any one time and is the sum of most of physical memory and the size of the paging file(s).
- Peak - This represents the total amount of committed virtual memory processes have allocated since the system booted which must be backed by physical memory or stored in the paging file.
The 'Commit Charge Limit' has to be large enough to support your workloads commit charge. If it is not, your processes won't be able to allocate the virtual memory they want and will fail to run correctly. I have illustrated what happens when you hit the 'Commit Charge Limit', in a best case scenario, at the bottom of this post.
If you are looking to manually size the paging file, the most appropriate way of doing so is too have a look at the 'Commit Charge Peak' value after you feel you have attained your maximum workload. The difference between that value and the amount of physical memory of the machine is the size of the paging file which you will need to support your workload. For example, if you have 4GB of physical memory and your workload requires a commit charge off 4.7GB, the paging file would need to be at least 700MB. This should be the bare minimum for the initial size of the paging file. You would want to add extra onto that value to give yourself some buffer. If you are interested in crash dumps, make sure it's large enough to accommodate them as well.
The most sensible option for the maximum size would be to set it to double what the initial size has been set too. Some people may suggest having the initial and maximum sizes the same value to prevent the paging file from expanding and contracting. Assuming this is an issue, the paging file will only grow when the 'Commit Charge Current' reaches the 'Commit Charge Limit'. As long as the initial allocation is sufficient, the paging file will never need to change in size and the larger maximum simply serves as a safety net.
If you have enough physical memory to support your workloads commit charge, you don't need a paging file and Windows will run perfectly fine without one. For example, you have a system which consists of 8GB of physical memory and your workload requires 5.6GB of commit charge. However, there are a couple of disadvantages with running with 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 dump files. This will also apply to cases where you have one, but it isn't large enough to support the crash dump you are configured for.
One last thing which is probably worth mentioning is regarding certain applications failing to run because the paging file has been disabled. Taking into account the role of the paging file, whether you have one or not shouldn't effect the functionality of the software which you're running. However, there does seem to be certain applications (Dawn Of War II being an example) which genuinely won't run if there is no paging file. I couldn't quite understand the reasoning behind this so I thought I would send Mark Russinovich a message via his
blog, and this was his response.
Mark Russinovich said:
These apps could very easily be querying directly for the existence of a paging file and failing if one’s not present, based on the misconception that one is necessary.
Applications which fail to run due to the above should not be confused with the issue of hitting the system commit limit, which may give the illusion a paging file is necessary and a particular application requires one. That seems to have originated from the fact that people are disabling the paging file without any regard to how much commit charge their workload requires.
---------------------------------------------------------------------------------------------
Following on from the above, I am just going to illustrate what happens when you hit the system commit limit. My system has 4GB of physical memory and the initial and maximum size of the paging file has been set to 1024MB. This means the system commit limit is roughly 5GB. I ran a tool called
Testlimit and directed it to allocate 2GB of private committed virtual memory by using the -m switch. As I reached the system commit limit, my processes were unable to allocate the virtual memory they wanted and Windows popped up a message telling me I was low on memory.
---------------------------------------------------------------------------------------------
If anyone is interested in this sort of thing, the following links are well worth looking at.
Papers:
Videos:
