LKBEN10695: Does PAE makes sense on a citrix or microsoft terminal server system

Symptom

You ordered a system with more than 4 GB of RAM and are not shure if it makes sense with a 32 Bit OS

Cause

32 Bit systems have some limitations which 64 Bit systems do not have

Solution

Overcomming the limitations of 32 Bit is inherent complex.

Pysical Address Extentions also called PAE x86 is a technology that increases the amount of physical or virtual memory available to user mode applications. It is one of two technologies that increase the amount of RAM. The other technology is 4-gigabyte tuning or 4GT.

By default, servers running the 32-bit editions of Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, support only 32-bit memory addressing and thus are able to access only 4 gigabytes (GB) of physical memory. However, hardware that offers much larger amounts of physical memory is available. Both the operating system and many applications can benefit from using this additional memory.

PAE X86 allows servers running Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, on a 32-bit hardware platform to access physical memory beyond 4 GB. To do this, PAE changes the memory addressing from 32-bit addressing mode to 64-bit addressing mode, allowing the operating system and high performance drivers and applications access to the additional physical memory. When using the larger amount of physical memory made available by PAE X86, operating system performance can be increased, particularly when the server is hosting multiple applications. Applications can also have direct access to the physical memory beyond 4 GB provided they use the Address Windowing Extensions (AWE) API set.

Please note that no normal applications you are running on your citrix terminal server uses this AWE API. As a consequence your applications do not overcome the 32 Bit limitations.

When using PAE X86, all of the physical memory in the system is treated as general purpose memory. The operating system is able to use this memory for caching and virtual memory management without major changes.

Please note that your OS can use this extra memory for caching and virtual memory management which indirectly gives your applications more memory.

Applications can also use this memory without major changes. The most noticeable difference is that more applications can be running before paging occurs because there is more memory for each process and its associated virtual address space. This also means that more processes can be resident in memory. Because applications not needing larger physical memory do not need to be modified or use the AWE API set, virtually all applications can benefit from PAE X86.

What is it now, can the applications use it or not?

The applications can NOT address extra memory because the 32 Bit pointers stay 32 Bit long. The OS can use this extra memory and by putting more cache over the 4 GB limit and by changing the virtual memory manager the applications think they have more memory available.

A bit more in detail:
PAE X86 allows the Windows executive software (known as the kernel) to take full advantage of all available physical memory, including memory above 4 GB, up to 64 GB. This can result in a significant reduction in paging operations and can improve the performance of the server when multiple applications are hosted on a single computer, such as in application consolidation scenarios.

Additionally, certain data-intensive applications (which you do not run on your normal terminal server systems), such as database management systems and scientific and engineering software that need access to very large caches of data can also use PAE to address memory beyond 4 GB. These applications can use the AWE API to access up to 64 GB of memory using a memory window inside their 4 GB process. Just four system calls are used to declare the AWE window and to map additional physical memory inside that window.

Please note that PAE X86 is not required on the 64-bit versions of Windows.
 
When the OS changes the Memory Manager, what happens then?

The memory manager translates virtual memory addresses used by the operating system and applications to actual physical memory locations. The translation of virtual memory to physical memory is transparent to the application. User mode processes are never able to directly write to real memory and never actually know where their data resides. A user mode process can request a block of memory and write to it. The data written to the memory location might be written to real memory, or might be written to a paging file. A paging file, known as a swap file, is a file on the hard disk that the memory manager uses to hold data that does not fit in memory. The memory manager moves data from the paging file to memory as needed and moves data from memory to the paging file to make room for new data.

So, an application needs the memory manager to assign RAM to it. As a consequence, when you change the memory manager you can make applications think they have more resources. The application does not have to be changed. The application can not address more RAM by doing this but we have more to share between the applications because the OS can use memory above 4 GB. (e.g. for caching)

Now, we come back to our question. Is it usefull to buy more than 4 GB of memory for terminal services or citrix systems?

The answer is YES but you might be better of by saving the money and bying an extra server. You will be able to serve more users by buying 6 or 8 GB. I have seen 6 till 12 additional users per system. All you need is a version of the OS which has PAE (at least the enterprise edition). would however save the money for the extra RAM and for the enterprise edition of windows and invest this money in an extra server. I think you can handle more users for the same money. If possible, use the 64-Bit version of windows. In this case you do not have to do anything. To bad that there are no 64-Bit applications on windows. ;-)

Disclaimer:

About the Author

Author: Wim Peeters - Keskon GmbH & Co. KG

Wim Peeters is electronics engineer with an additional master in IT and over 30 years of experience, including time spent in support, development, consulting, training and database administration. Wim has worked with SQL Server since version 6.5. He has developed in C/C++, Java and C# on Windows and Linux. He writes knowledge base articles to solve IT problems and publishes them on the Lubby Knowledge Platform.