PAE or 64bit?

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?

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?

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!

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    

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.

Thanks all