Php – x86/32bit PHP on 64bit Windows Server 2008

Most modern 32-bit CPUs support PAE which allows them to address more than 4GB of physical memory, although a single process can only see 4GB at a time. The kernel will take some of this address space. This Stackoverflow post discusses how PAE works.

Many operating systems (including Linux and MS Windows) offer an API that allows you to manipulate the MMU and page overlays in and out of the virtual address space of a process. This facility allows you to use extra memory for disk buffers. However, as far as I am aware the only DBMS platform with direct support for this is MS SQL Server.

Additional memory will improve your database read performance (which will probably improve your overall throughput), but write performance will be constrained by I/O. If you have a low DB cache hit rate (say less than 95%) then additional memory will probably improve your overall throughput. Otherwise, you may need to look at your disk subsystem (see 1 below).

Assuming you need or can benefit from more memory, the best approach is to move to a 64 bit platform. A modern Xeon or Opteron server will let you install up to 32-144GB depending on the model. This is likely to be your best option.

1. SANs are good for transactional applications. For a high-volume application you should have write-through caching on the DB logs but you may be able to get away with write-back caching on the data volumes. This will get you good log-reader performance as the random data writes can be absorbed by the controller's battery-backed cache and the controller can optimise disk writes to improve throughput.
   
   However, this arrangement has failure modes that can leave the data volumes inconsistent (corrupted). Using write-through on the log volumes mitigates this (as the logs are not vulnerable to these failure modes). Practicaly this limits you to a restore/roll-forward recovery model, so it will only work if you can tolerate a (say) 4-hour recovery window.

If you're talking about installing a host, you should go 64 bit. It sounds like you're talking about a guest, though, and since you mention that rather small amount of memory, I think you'd be better off going with 32 bit for the guest.

The biggest advantage to 64 bit is native addressing of large amounts of memory, and you obviously won't hit the 4 gig limit. Plus I've heard of some cases where 64 bit can be potentially slower for certain applications.

I can think of no advantage for using 64 bit operating systems on a system, virtual or real, with less than 4 gig of memory.

Some reading material on the topic can be found at the Wikipedia and here.

While I would personally probably opt to just slap in the 32 bit guest, it also depends on what you're going to do...if you're really concerned, you should probably install both versions (as a minimal Debian shouldn't eat a lot of install space) and test it with the configuration you're intending to use the VM for and see what you can do with benchmarking. With your memory being low there's no clear way to go one way or the other...so if you're concerned you'd have to actually try testing both. Create three partitions, install the OS 32 and OS 64 in partitions one and two, and use a data partition (okay, four partitions, since you'd have to have swap space most likely set up too).