Linux – 64bit or 32bit Linux system

32-bit64-bitlinuxslackware

I have a server that has 4GB of RAM. On it, I have installation of 32bit Slackware Linux 12.1. Of course, it is not using all of 4GB of RAM. I'd soon like to increase the RAM to 8GB, and am looking for a way for the system to use it. The system is used as a database server and is under high load during the day.

AFAICT, I have two options: stay with 32bit and rebuild the kernel and lose some performance. Or go with 64bit and reinstall everything. Looking at 64bit versions of Slackware, I could run -current or Slamd64.

Now, on to the questions:

  1. Should I stay with 32bit or go with 64bit?

  2. If I go 64bit, should I use -current or Slamd64?

P.S. I hope to get answers from someone actually using any of these configurations in production, not just copy/paste something I could find myself via Google.

Best Answer

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.
Related Topic