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
Stefan,
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.
Cheers,
Stefan
What about the /3GB switch?
http://support.microsoft.com/default.aspx/kb/933560
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.
http://support.microsoft.com/default.aspx/kb/283037
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?
The SharePoint Swiss Army Knife 
Go 64-bit is all I’m going to say.
There’s no need whatsoever to run 32-bit operating systems anymore, not even on the desktop end even less so on a server.
Believe it or not, I’m working with some very large US companies that have not yet approved the use of 64-bit operating systems for a variety of reasons including internal support mechanisms for 64-bit computing, compatibility with legacy systems and security software/protocols that have not yet ported their software to 64-bit. Doh!
To imagine something perceptually, we put ourselves in a conscious state resembling the thing itself. ,