PAE or 64bit?


We have an application running on a Windows 2003 Server Enterprise x32 (running on VM). It has 4GB RAM.

Recently, we had a few memory issues with the app and the vendor has released an upgrade. But they admit that the app may require a lot of memory.

So we have the following options

1. Upgrade the app and hope everything works out fine

2. Upgrade the app. If we need more memory, we can assign more to the VM guest and use the PAE switch so the OS/app can see this extra memory

3. Rebuild the app on a 64 bit server

Note - we have server hardware refresh coming in a year anwyway where we'll be going to 2008 R2 which I understand is 64bit anyway.

I was interested in people's opinions. Is there any reason why we shouldn't go for the PAE switch?

Secondly, from a VM point of view, is there any reason not to go for 6GB RAM on those virtual application servers?
Who is Participating?
My opinion is that you should go for 64 bit, however ensure the application has a 64 bit version, otherwise is just the same case.
PAE is just a workaround and don't think it will do you good.
neil4933Author Commented:
Hi there

Sorry should have mentioned the application itself is 32bit.

So you are saying that going to 64bit will have no major effect for a 32bit app?
Neil RussellTechnical Development LeadCommented:
Nope. Hardly any at all. The only difference is that the OS itself can use memory from the rest of available memory and leave your app with the maximum that a 32bit app will access.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
personally, I would ignore what the vendor is saying (for the moment), and test the application on the server, and prove what they are stating.

e.g. at implemtnation stage test the new upgrade with the users before going production on the final platform.

I've worked with lots of vendors claiming their application needs 4GB, 8GB, these have now been running in production for 4-5 years, and their servers which were allocated this amount of resource has now been cut back to 1G and 2G with no issues.

Some Vendors not all (never test), and have no idea, what their applications will consume.

just my 2 pence worth.
Tried Citrix with PAE on a physical box and Enterprise x32 with 32GB of RAM.  Not so good.  :-(

It works, but sometimes there are memory leaks.  I reboot every week and that seems to help.
neil4933Author Commented:
Thanks all - will definately test.

So, to summarise, using a 32bit app on a 64bit OS is not really going to help since the app won't be able to access this extra memory. In that case, PAE will not help either will it?

On the flip side though, if the app has multiple processes, then each can max out their 2GB share of the 4GB address space they are given in virtual memory. Am I correct?

Finally, out of interest, if a 32bit app has 4GB memory virtual address space, split between OS and app, how does this work for a 64bit app?
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
OT Citrix Servers - Our farm (8,000 current users) of 96 1U servers We reboot then every 24 hours! (2P 4G Win2k3) because of this, so if you are getting a week, before reboot, thats very good!
This maybe a discussion best broken into 2 explainations.
32bit and PAE
PAE is the ability to effectively enable 36bit memory (only) addressing on a 32bit OS. This gives a practical limitation of 16GB of addressable memory (the book says much more BUT).
This is all good and well but if your applications aren't PAE aware they can't use memory over the 4GB boundary anyway.
Also enabling PAE doesn't increase either of the paged or nonpaged memory pools. Therefore of you have a highly transactional or workitem related load you will likely experience memory pool limitations as the next bottle neck.

The 64bit environment doesn't suffer any of the memory pool issues x86 does, it also solves your issue with addressing large volumes of RAM.
In theory if your application is 32bit but doesn't make any 16bit calls it will run on a 64bit OS, it will still of course (generally) suffer the 4GB memory limits imposed by it ability to 32 bit adderessing.

If the vendor has a version of your application that's supported on a x64 OS it would be wise to use it, even if this supported version is a 32bit application.
Win2k8 is another ball game and your right R2 is only available as a 64bit OS.
If you have no Win2k8 experience it may not be best to start with your most critical application. ( LAB it for a while first)
Hope this helps you decide.
neil4933Author Commented:
Thanks Mark...could you expand on this comment by any chance?

"Also enabling PAE doesn't increase either of the paged or nonpaged memory pools. Therefore of you have a highly transactional or workitem related load you will likely experience memory pool limitations as the next bottle neck"
Sure Neil
Windows 2003 is the OS I'll talk about.
There are 2 primary memory pools the Windows OS employes to manage OS style functions, these are the pool and nonpooled memory pools. Of these the one which usually bring the OS down is the nonpaged memory pool.
This pool os a fixed size of 256MB, but if your OS manages to consume more than say 230MB it's doomed. (by the time it gets to 230MB it's so busy trying to manage the non paged pool which it actually requires to manage the non paged pool it hangs and reboots) See the catch 22.
With out going into all this gaff
Think of it like a bucket. The bucket is 256MB.
For instance each IO function uses a work item which requires a portion of memory to be allocated from the non paged pool. Once that function is complete the memory is returned to the non paged pool.
If you have more requests inbound than can be serviced by the OS the work item requests will be cached until the non paged pool is exausted. Because the OS uses workitems it's self it will at this point fall over.
Why would this occur, it could be that your SQL Server is very busy, it's requesting so much data from disk that the disk subsystem is always queueing request, the IO queue means workitems at the OS level are also being queued and therefore not serviced a a sufficient pace to maintain the application requests for resources.
Faster HDD may solve this issue in the short term but in todays age a 256MB non paged pool is insufficient.
The x64 OS has a non paged pool in the 10 of GB I don't recal the actual figure.
Of course there is considerable tuning you can do with non paged pool and paged memory pools. I'm sure over the years I've touched many of these settings generally in the way of registry keys, but the one thing learnt is they are only temporary fixes..
Go x64 if you can, also you need to be aware there is generally a larger HDD foot print and RAM foot print with most x64 implementations over x32    
Has the vendor indicated that they will be releasing a 64-bit version of the application? If so I would look at 64-bit as a long term direction to take, but not necessarily short term.

As has been mentioned the /PAE switch will allow the OS to address more than 4GB of RAM, and run multiple applications and utilize the more memory. This will not be of much help if you are running a single application that has high memory requirements.

If the single application high memory requirements is your scenario I would recommend looking into the /3G switch (possibly in conjuction with /PAE, they are not exclusive). Normally 32-bit Windows splits memory into 2GB for the OS, and 2GB address spaces for the various applications. The /3G switch changes that ratio to 1GB for the OS and 3GB for the applications. For a 32-bit application running short on memory in the 2GB it has allocated this switch may do some good.

Hope this helps
neil4933Author Commented:
Thanks both.

To confirm my understanding:

1. PAE will not change anything related to virtual memory. The app will still have 2GB process/2GB OS per process. The only thing it changes is how much memory the OS sees so that more physical memory (RAM) can be used instead of paging it off.

2. The /3GB switch will provide the application process 3GB of virtual address space instead of the usual 2GB

3.  If we use the /3GB switch, the app should have been coded to support this. Either way, the app can only access either 2GB (or 3GB with the switch) per virtual address space

4. Either way, with either /3GB or PAE, the existing NPP and Paged Pool memory limitations still apply. So am I correct in thinking that if we use either of these switches, we are more likely to hit the NPP/Paged Pool limitations as there are more  requests likely to be queued? To be honest, I'm still not 100% sure I understand this one :)
The app shouldn't need to be coded specifically for the /3G -  it is still just 32-bit addressing of the 4GB address space and should be transparent to the application. It affects the partitioning of that 4GB space between application and OS processes.

However, in regards to the NPP the limitation goes from 256 MB without the /3G switch to 128 MB if you turn it on. So if you are suffering from a shortage on non-paged pool the /3G switch might not be for you. Heavily multithreaded applications like IIS tend to use NPP more agressively then monolithic applications.

Perhaps the best thing to do would be to try it and test. First get a baseline on the performance counters, then observe them again after the change.

Good Luck
If you think the application will require more than 3 GB of RAM a 32bit OS is not going to cut it.
I would strongly suggest you go down the x64 OS path. Ideally you want vendor support but if they don't support it I'd test it regardless.
In a high memory and non paged pool usage environment a 32bit OS is a backwards step.
neil4933Author Commented:
Thanks all
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.