So you think you can haXor 32-bit SharePoint by using Windows 2003/2008 Enterprise eh? Guess again…

Although I haven’t been really able to find a definitive Technet/MSDN article on this issue anywhere, I have come across some tidbits of information that suggests otherwise. Just because the 32-bit Enterprise versions of Windows Server 2003 can support more than 4GB of RAM by way of the /PAE switch, that doesn’t mean 32-bit SharePoint can take advantage of that extra memory.

Back in November ’08, I was on a troubleshooting call with MSFT support. We had asked them about the option of using either the /3GB or /PAE to improve SharePoint performance and they had responded with a negative. Here are some links I’ve come across to reaffirm this fact:

Thursday, November 20, 2008 5:48 PM by MattMossDeveloper
# re: Dealing with Memory Pressure problems in MOSS/WSS
Would it be possible to get your sharepoint w3wp to use more memory if you had a windows 2003 enterprise server (8 gig ram) with PAE enabled?

Thursday, November 20, 2008 5:58 PM by Stefan_Gossner
# re: Dealing with Memory Pressure problems in MOSS/WSS
Hi Matt,
no this will not help. PAE allows a computer to address more physical memory. Not more virtual memory.
The virtual memory of a process is always 4GB. 2 GB system and 2 GB user mode RAM.
So PAE would allow you to run more processes without a need of paging. But not to address more memory within a single process.

What about the /3GB switch?

Reducing the size of the kernel mode memory buffers when in /3GB mode causes unacceptable performance in Windows SharePoint Services file-transfer operations. Therefore, a decision was made not to support the /3GB switch in Windows SharePoint Services. Windows SharePoint Services will run if you use the /3GB switch. However, the operating system will become unstable in scenarios in which the server is under stress.

My best guess is that the 32-bit SharePoint code base was not developed to support AWE which is a requirement for PAE compatibility.

AWE is a set of application programming interfaces (APIs) to the memory manager functions that enables programs to address more memory than the 4 GB that is available through standard 32-bit addressing. AWE enables programs to reserve physical memory as non-paged memory and then to dynamically map portions of the non-paged memory to the program’s working set of memory. This process enables memory-intensive programs, such as large database systems, to reserve large amounts of physical memory for data without having to be paged in and out of a paging file for usage. Instead, the data is swapped in and out of the working set and reserved memory is in excess of the 4 GB range. Additionally, the range of memory in excess of 4 GB is exposed to the memory manager and the AWE functions by PAE. Without PAE, AWE cannot reserve memory in excess of 4 GB.

I don’t argue the merits of /PAE for operating systems though. Unfortunately it doesn’t seem to be relevant for today’s 32-bit SharePoint environments. Anybody want to argue otherwise?