Memory management under Window OS

The 4GB limit

In the default Windows configuration, 2 GB of this virtual address space is designated for private use of every process, and the other 2 GB is shared between all processes and the operating system. Typically, applications such as Notepad, Microsoft Office Word, and Adobe Acrobat Reader use only a fraction of the 2 GB of private address space. 

The only way to increase the size of the virtual address space for a process beyond 4 GB is to use 64 bit hardware with a 64 bit version of the operating system and application built for the 64 bit instruction set.

The nub of it is, that no matter how much physical RAM is in the computer, the amount of memory available in the process’ private part of the virtual address space in 32 bit Windows implementations is limited to:

• 2 GB - without the /3GB switch - this is the normal, default maximum private virtual address space

or

• 3GB with the /3GB switch (also called Application Memory Tuning) AND the application modification mentioned in http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx 

or

• any physical RAM not used by the OS and other applications by designing the application to use the AWE (Address Windowing Extensions) API. 

How to enable the 3GB support in an application:

“No APIs are required to support application memory tuning. However, it would be ineffective to automatically provide every application with a 3-GB address space. Executables that can use the 3-GB address space are required to have the bit IMAGE_FILE_LARGE_ADDRESS_AWARE set in their image header. If you are the developer of the executable, you can specify a linker flag (/LARGEADDRESSAWARE).

To set this bit, you must use Microsoft Visual Studio Version 6.0 or later and the Editbin.exe utility, which has the ability to modify the image header (/LARGEADDRESSAWARE) flag. For more information on setting this flag, see the Microsoft Visual Studio documentation.”

Memory, Committed Bytes:

This is a measure of the demand for virtual memory. It shows how many bytes have been allocated by processes and to which the operating system has committed a RAM page frame or a page slot in the pagefile (or both).

Process, Working Set, _Total:

The amount of virtual memory in "active" use. It shows how much RAM is required so that the actively used virtual memory for all processes is in RAM.

Paging File, %pagefile in use:

How much of the pagefile is actually being used. This is the counter you should use to determine whether the pagefile is an appropriate size. If this counter reaches 100, the pagefile is completely full and operations stop working. Set the pagefile large enough so that no more than 50 to 75 percent of it is used. If a large part of the pagefile is in use, having more than one pagefile on different physical disks may improve performance. 

Memory, Pages Output/Sec:

This shows how many virtual memory pages were written to the pagefile to free RAM page frames for other purposes each second. This is the best counter to monitor if you suspect that paging is your performance bottleneck. Even if the Committed Bytes value is greater than the installed RAM, a Pages Output/sec value that is low or zero most of the time indicates that there is not a significant performance problem that is caused by not enough RAM.