In modern operating systems, including Windows, application programs and many system processes always reference memory using virtual memory addresses which are automatically translated to real (RAM) addresses by the hardware.� Only core parts of the operating system kernel bypass this address translation and use real memory addresses directly.�
�
Virtual Memory is always in use, even when the memory required by all running processes does not exceed the amount of RAM installed on the system.
�
An expanded version of this article is available at http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm.
�
�
Processes and Address Spaces
�
All processes (e.g. application executables) running under 32 bit Windows gets virtual memory addresses (a Virtual Address Space) going from 0 to 4,294,967,295 (2*32-1 = 4 GB), no matter how much RAM is actually installed on the computer.�
�
In the default Windows OS configuration, 2 GB of this virtual address space are designated for each process� private use and the other 2 GB are shared between all processes and the operating system.� Normally, applications (e.g. Notepad, Word, Excel, Acrobat Reader) use only a small fraction of the 2GB of private address space.��The operating system only assigns RAM page frames to virtual memory pages that are in use.�
�
Physical Address Extension (PAE) is the feature of the Intel 32 bit architecture that expands the physical memory (RAM) address�to 36 bits (see KB articles 268363 and 261988). �PAE does not change the size of the virtual address space, which remains at 4 GB, just the amount of actual RAM that can be addressed by the processor.
�
The translation between the 32 bit virtual memory address used by the code running in a process and the 36 bit RAM address is handled automatically and transparently by the computer hardware according to�translation tables maintained by the operating system.� Any virtual memory page (32 bit address) can be associated with any physical RAM page (36 bit address).
�
Here's a list of how much RAM the various Windows versions and editions support (as of�Nov 2004):
�
���� Windows NT 4.0: 4 GB
���� Windows 2000 Professional: 4 GB
���� Windows 2000 Standard Server: 4 GB
���� Windows 2000 Advanced Server: 8GB
���� Windows 2000 Datacenter Server: 32GB
���� Windows XP Professional: 4 GB
���� Windows Server 2003 Web Edition:�2 GB
�� � Windows Server 2003 Standard Edition: 4 GB
���� Windows Server 2003 Enterprise Edition: 32 GB
���� Windows Server 2003 Datacenter Edition: 64 GB
�
Pagefile
�
RAM is a limited resource, whereas virtual memory is, for most practical purposes, unlimited.� There can be a large number of processes each with its own�2 GB of private virtual address space.� When the memory in use by all the existing processes exceeds the amount of RAM available, the operating system will move pages (4 KB pieces) of one or more virtual address spaces to the computer�s hard disk, thus freeing that RAM frame for other uses.� In Windows systems, these �paged out� pages are stored in one or more files called pagefile.sys in the root of a partition.� There can be one such file in each disk partition.� The location and size of the page file is configured in SystemProperties, Advanced, Performance (click the Settings button).
�
A frequently asked question is how big should I make the pagefile?� There is no single answer to this question, because it depends on the amount of installed RAM and how much virtual memory that workload requires.� If there is no other information available, the normal recommendation of 1.5 times the amount of RAM in the computer is a good place to start.� On server systems, a common objective is to�have enough RAM so that there is never a shortage and the pagefile is essentially, not used.� On these systems,�having a really large pagefile may serve no useful purpose.� On the other hand, disk space is usually plentiful, so having a large pagefile (e.g. 1.5 times the installed RAM) does not cause a problem and eliminates the need to fuss over how large to make it.�
�
Performance, Architectural Limits and RAM
�
On any computer system, as load (number of users, amount of work being done) increases, performance (how long it takes to do each task) will decrease, but in a non linear fashion.��Any increase in load (demand) beyond a�certain point will result in a dramatic decrease in performance.� This means that some resource is in critically short supply and has become a bottleneck.
�
At some point, the resource in critical short supply can not be increased.� This means an architectural limit has been reached.� Some commonly reported architectural limits in Windows include:
�
� 1. 2 GB of shared virtual address space for the system
� 2. 2 GB of private virtual address space per process
� 3. 660 MB�System PTE storage
� 4.�470 MB paged pool storage
� 5. 256 MB�nonpaged pool storage
�
The above applies to Windows 2003 Server specifically (from Knowledgebase article 294418), but also apply to Windows XP and Windows 2000.
�
Commonly found and quoted statements such as:
�
�� with a Terminal Server, the 2 GB of shared address space�will be completely used before 4 GB of RAM is used
�
may be true in some situations, but you need to monitor your system to know whether they apply to your particular system or not.� In some cases, these statements are conclusions from specific�Windows NT 4.0 or Windows 2000 environments and don't necessarily apply to Windows Server 2003.� Significant changes were made to Windows Server 2003 to reduce the likelihood that these architectural limits will in fact be reached in practice.� For example, some processes that were in the kernel have been moved to non kernel processes to reduce the amount of memory used�in the shared virtual address space.
�
Monitoring RAM and Virtual Memory usage
�
Performance Monitor (Start, Administrative Tools, Performance) is the principle tool for monitoring system performance and identifying what the bottleneck really is.��Here's a summary of some important counters and what they tell you.
�
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 (perhaps both).� As Committed Bytes grows above the amount of available RAM, paging will increase and the amount of the pagefile in use will also increase.� At some point, paging activity will start to significantly impact perceived performance.
�
Process, Working Set, _Total - this is a measure of 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.�This is always a multiple of 4,096, which is the page size used in Windows.� As demand for virtual memory increases above the available RAM, the operating system will adjust how much of a process's virtual memory is in its Working Set to optimize the use of available RAM and minimize paging.
�
Paging File, %pagefile in use - this is a measure of how much of the pagefile is actually being used.
��������� This is the counter to use to determine if the pagefile is�an appropriate size.� If�this�counter gets to 100, the�pagefile is completely full and things will stop working.� Depending on the volatility of your workload, you probably want the�pagefile large enough so that it is normally no more than 50�- 75% used.��If�a lot of the pagefile is in use, having more than one on different physical disks, may improve performance.�
�
Memory, Pages/Sec - this is one of the most misunderstood measures.�
��������� A high value for this counter does not necessarily imply that your performance bottleneck is shortage of RAM.� The operating system uses the paging system for purposes other than swapping pages due to memory over commitment.
�
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 Committed Bytes is greater than the installed RAM, if Pages Output/sec is low or zero most of the time, there is not a�significant performance problem from not enough RAM.
�
Memory, Cache Bytes
Memory, Pool Nonpaged Bytes
Memory, Pool Paged Bytes
Memory, System Code Total Bytes
Memory, System Driver Total Bytes
��������� The sum of these counters is a measure of how much of the 2GB of the shared part of the 4 GB virtual address space is actually in use.� Use these to determine if your system is reaching one of the architectural limits discussed above.
�
Memory, Available MBytes - this measures how much RAM is available to satisfy demands for virtual memory (either new allocations, or for restoring a page from the pagefile).
��������� When RAM is in short supply (e.g. Committed Bytes is greater than installed RAM), the operating system will attempt to keep a certain fraction of installed RAM available for immediate use by�copying�virtual memory pages that are not in active use to the pagefile.� For this reason, this counter will not go to zero and is not necessarily a good indication of whether your system is short of RAM.
�
↑ Back to the top
Microsoft corporation and/or its respective suppliers make no representations about the suitability, reliability, or
accuracy of the information and related graphics contained herein. All such information and related graphics are provided
"as is" without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions
with regard to this information and related graphics, including all implied warranties and conditions of merchantability,
fitness for a particular purpose, workmanlike effort, title and non-infringement. You specifically agree that in no event
shall Microsoft and/or its suppliers be liable for any direct, indirect, punitive, incidental, special, consequential
damages or any damages whatsoever including, without limitation, damages for loss of use, data or profits, arising out
of or in any way connected with the use of or inability to use the information and related graphics contained herein,
whether based on contract, tort, negligence, strict liability or otherwise, even if Microsoft or any of its suppliers has
been advised of the possibility of damages.
↑ Back to the top
