Tuesday, February 28, 2012 2:19 AMBasically I need to know whether when Windows pages some memory to disk, whether it frees the physical memory straight away, or only drops the page from physical memory when it is needed for another program.
My thoughts are that the page exists only in the pagefile or physical memory, and is moved back and forward as needed.
However wouldn't it be more efficient to do this:-> Low on memory?-> Copy contents of memory to disk (Same selection as normal paging)-> Leave copy of memory in physical until another process makes a request we cannot fulfill.-> If the copied memory is written to before it is dropped, then mark the copy in the pagefile as dirty.
Monday, March 05, 2012 7:52 AM
The page file is one of those pieces of the operating system that administrators know that they need to have - but they can't always explain why they need it, or how to accurately size it. Since Windows 95, Windows-based operating systems have used a special file that acts as a sort of "scratch pad" to store modified pages that are still in use by some process. Page file space is reserved when the pages are initially committed, however the page file locations are not chosen until the page is written to disk. So, in simplistic terms, the page file is used by Windows to hold temporary data which is swapped in and out of physical memory in order to provide a larger virtual memory set.
When the system boots up, the Session Manager process determines the list of page files to open by reading the value in the HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PagingFiles. This value contains the name of the paging file as well as the minimum and maximum size of each paging file. Windows supports up to 16 page files. On a 32-bit system running the normal kernel, the maximum size of each page file is 4095 MB. On x64 systems and x86 systems with the PAE kernel, the maximum page file size is 16 terabytes (16TB). On IA-64 systems, each page file can be as large as 32 terabytes.
The page file needs of an individual system will vary based on the role of the server, load etc. There are some performance counters that you can use to monitor private committed memory usage on a systemwide or per-page-file basis. There is no way to determine how much of a process' private committed memory is resident and how much is paged out to paging files.So with this information in mind, what's the best way to determine the correct page file size? The first thing is to gather a baseline. Set up a page file that is statically sized to 1.5GB of RAM. Then monitor the server using Performance Monitor over a period of time. Ensure that the peak usage times of the server are monitored as this is when the server will be under the most load (for example, month-end / year-end processing etc). Using the information from the counters above and also examining the Peak Commit Charge number in Windows Task Manager (shown below) will give you an idea how much page file space would be needed if the system had to page out all private committed virtual memory.
If the page file on the system is too large, the system does not use it any more or less. In other words, increasing the size of the page file unnecessarily does not change the system performance - it just means that the system has more nonshareable committed virtual memory. If the page file is too small on the other hand, you may see error messages such as the "system is running low on virtual memory".
Remember however, that you should also check whether there is a process that is leaking memory or a pool memory leak as those will also cause error messages relating to system resources and virtual memory to be displayed.
What is the Page File for anyway?
How to determine the appropriate page file size on my server
RAM, Virtual Memory, Pagefile and all that stuff
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.