x64? My Terminal Servers Run Just Fine With 32 Bits and 8/12/16 GB RAM!

Helge Klein, 05/25/2008 | 8 Comments | 36,619 Views

A recent discussion with a colleague brought this topic to my attention which I have not discussed in detail in my series on Windows x64:

Memory scalability of 32-bit Terminal Servers

Many people seem to think that on 32-bit Windows only specially adapted applications can access memory above 4 GB. Since such applications are rare that would effectively mean that putting more than 4 GB RAM into a terminal server is a waste of resources.

Luckily, things are different. To understand why, we must take a look at the x86 processor architecture.

AWE

32-bit processes can, of course, only address 4 GB RAM because 2^32 equals 4 GB. But this limit can, like many other restrictions, be overcome with tricks. In this case the "trick" is called Address Windowing Extensions (AWE), a Windows API that allows 32-bit applications to access more physical memory than they have virtual address space. With AWE, memory above the 4 GB "barrier" can be accessed by mapping portions of it into the space below 4 GB. By moving this mapped slice around, a practically unlimited amount of memory can be accessed.

Now this moving around business may sound easy, nevertheless applications need to actively do it if they need more than 2 GB of memory (remember, half of each process's virtual address space is reserved for the kernel). This is typically the case for large databases.

On terminal servers the situation is entirely different. Here we typically have many concurrently running processes each using less than 2 GB RAM. And here comes the good news: using more than 4 GB RAM is a no-brainer and requires no changes whatsoever to your applications. So how does it work?

PAE

Windows can be booted with the /PAE option. PAE makes the kernel use 4 additional address lines which are built into (nearly) every CPU since the Pentium Pro. Modern CPUs have 36 instead of 32 address lines and support a maximum of 64 GB RAM (with PAE enabled).

But how can a traditional 32-bit application that can only count to 2^32 and that knows nothing of AWE access such "high" memory?

Easy: all the hard work is done by the operating system. Remember that each application has its private virtual address space that always ranges from 0x00000000 to 0xFFFFFFFF. But programs cannot simply access any address in that range. Doing so would result in the well-known general protection fault. Instead applications must request memory from the OS. The OS then chooses the appropriate amount of free pages (RAM is managed in units of pages with a size of 4 KB each). Finally the pages are mapped from physical RAM into the virtual memory of the requesting process.

By virtualizing the address space of processes, it has become irrelevant to applications where a page actually is located. It could have been moved to disk (to the page file, of course) to make room for other process's demands. Or it could reside in the area above 4 GB. Since applications only work with virtual addresses in the 32-bit range they need not be modified as long as they use less than 2 GB of memory.

With PAE, multiple 32-bit processes without AWE support can still only use 2 GB each. But it is perfectly possible to have 20 applications on a terminal server that each need 300 MB RAM if the machine is equipped with 8 GB (leaving room for the kernel and OS). This is because the map from virtual to physical memory is different for every process.

Caveats

Drivers, again.

Drivers often access physical memory directly. Badly written drivers use only 32-bit pointers and are thus not able to count higher than to 4 GB. That is the reason why Windows XP and Vista only support 4 GB RAM. Microsoft feared, bad drivers for consumer hardware would cause too many crashes on systems with more than 4 GB of memory.

And money.

Windows Server 2003 and 2008 support more than 4 GB RAM only in the Enterprise Editions. Those are significantly more expensive than the Standard Editions which are most often used for terminal servers.

Terminal Server Farm Scalability

In total, there are three options to scale your terminal server farm:

  • Use PAE and install more than 4 GB RAM per server (requires Enterprise Edition of Windows)
  • Install more than 4 GB RAM and reinstall every Server with Windows x64
  • Add more servers to the farm

Each of these options has its own little problems and drawbacks. But that is a topic for another article.

Side notes

Did you know that PAE is very likely enabled on the system you are currently working on? Every Windows since XP XP2 enables PAE if the CPU supports the no-execute (NX) feature because NX relies on PAE.

32-bit terminal servers will only scale up (by adding more RAM) if the system is not kernel memory constrained. See my earlier article on kernel memory limitations for details.

Quotes

From Microsoft KB article #283037:

"To summarize, PAE is a function of the Windows 2000 and Windows Server 2003 memory managers that provides more physical memory to a program that requests memory. The program is not aware that any of the memory that it uses resides in the range greater than 4 GB, just as a program is not aware that the memory it has requested is actually in the page file."

"AWE is an API set that enables programs to reserve large chunks of memory. The reserved memory is non-pageable and is only accessible to that program."

+++ Your opportunity +++ Use Profile Migrator the new sepago product that makes migrating user personalities between different platforms a breeze.! Download your free version now!

8 responses for "x64? My Terminal Servers Run Just Fine With 32 Bits and 8/12/16 GB RAM!"

[...] databases need more

[...] databases need more than 2 GB of virtual memory. If you have such an application, consider using /PAE or, even better, moving to an x64 [...]

Hello, what about the size

Hello,

what about the size of the pagefile, if you use a 32 bit enterprise system with e.g. 8 GB RAM installed?
Should it be also 1,5 times of physical RAM?
Or is 4 GB the max. range in this case?

Thank you for your reply.

Best regards

Sven

Sizing the page file would

Sizing the page file would warrant an article of its own, but the short answer is: with PAE enabled there is no 4 GB barrier. Quoting Mark Russinovich:

"32-bit Windows has a maximum paging file size of 16TB (4GB if you for some reason run in non-PAE mode)"

Thank you for your writing

Thank you for your writing this article, it is very informative, especially how /PAE works with Terminal Servers. I understand that when using Windows Server 2003 R2 SP2 32bit Standard with 4GB of physical RAM installed, by default, the address space is divided into two equal chunks, 2GB for the Kernel and 2GB for User-mode processes.
If we use Windows Server 2003 R2 SP2 32bit Enterprise Edition and install more Physical RAM, say 16GB and use the /PAE switch so the OS now sees all of the 16GB, the address space is still divided as before, 2GB for the Kernel and 2GB for User-mode processes. Is this correct?

Additional Questions;

1. If using /PAE and 16GB of physical RAM, as above, can each application access its own chunk of 2GB from the additional 16 GB of physical RAM?
Meaning, the kernel gets 2GB, App1 can access 2GB of the additional 16GB, App2 can access 2GB of the additional 16GB, etc for each additional app.

2. Do the applications have to be /PAE aware to utilize the physical RAM beyond 4GB, for their allocated 2GB for User-mode processes?

3. OR do the applications only have to be /PAE aware to use more than the 2GB for User-mode processes?

Thanks for your help

0. yes 1. yes 2. no 3. yes

0. yes
1. yes
2. no
3. yes

Does windows 7 ultimate 32

Does windows 7 ultimate 32 bit use PAE and can it address more than 4gb ram. I bought a system with 6 gb ram.

All 32-bit Windows client

All 32-bit Windows client operating systems are (artificially) limited to 4 GB, see for example my slide here:
http://blogs.sepago.de/d/helge/2010/06/10/64-bit-the-final-frontier-slid...
So unless you install the x64 version of Windows, you can only use 4 GB out of your 6.

Very informative. Followed

Very informative. Followed you link in msdn article "Memory Limits for Windows Releases".
Why is Microsoft not capable of explaining this the way you did? Many developers mess up virtual address space with physical memory and state that all running programs together cannot use more than 2GB.