64bit or 32bit Linux system?

Per process memory on 32-bit systems is 4GB (which is divided into 3GB for the process and 1GB for the kernel, by default). If you want your database to be able to access more memory /per process/ you have little choice but to install a 64-bit operating system. If the limit of 3GB per process is not bothering you, you might as well stay with the current setup. There are other options to the 3GiB/1GiB division, btw, but they won't help you in your specific situation.

Further limits on per-process memory usage exist in the form of what is called 'ZONE NORMAL' which never exceeds a little below 1GiB (896MiB to be exact). When using memory above 1GiB (ZONE HIGHMEM), the kernel has to map that memory into ZONE NORMAL, creating even further possible bottlenecks. ZONE HIGHMEM does not exist on a 64-bit system, on which everything is ZONE NORMAL. This can be a good reason to go with 64-bit as well.

As for the 'having in production'-part: I don't even know what database you are using. My Oracle setups almost always run 64-bit for the exact reason I've stated above. I don't run Slackware in production though and don't know anyone who does.

My €0.02: go for 64-bit. The re-install is trivial compared to possible benefits.

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.

I'm nearly in the same scenario as you (Is there any reason to use 64bit MySQL (and OS) on small databases?), and from what I could find out: MySQL on 32bit can not use more than 2GB RAM per instance no matter what you do with your kernel.

If you're not running MySQL the situation might be different.

I think it would be better to ask the question, "Why would I stay with a 32-bit kernel?"

I went all 64-bit on every piece of hardware that supports it as soon as I could and I have no regrets. At work we are running PostgreSQL servers on 64-bit CentOS 5 with 32 GB RAM and it is pretty great (Except for certain limitations with PostgreSQL itself, but nothing to do with 32 or 64 bits.)

The main danger of running on a 32 bit system with lots of highmem (more than 8GB) is that the kernel could end up needing to allocate more data than what fits in ZONE_NORMAL. This means the machine can effectively run out of memory, even if there were still lots of high memory free.

Another issue is that the system will more aggressively reclaim kernel data structures like cached inodes, buffer heads and other caches that can help system performance.

The third issue is that, on a 32 bit system, no process will be able to effectively use more than 3GB of memory. This means that buying more than 4GB of memory is only useful if none of the processes on your system need all of the memory.

For these reasons it is recommended that if you buy a system with more than 4GB of memory, you should consider getting a 64 bit CPU and installing a 64 bit operating system. The price difference between 32 and 64 bit systems is practically nonexistant, so there is no real need to experience the pains of highmem any more...

More info...

64-bit is the only way. On 32-bit, it's an inventive hack to get to >1GB, and an even bigger hack for >4GB.^[1] You say it's a heavily loaded system, so why waste cycles in a bodge to get to memory when it can be mapped directly?

The only reason you should use 32bit is for vendor support. As you're on Slackware, I doubt that would be a reason.

_{^[1] See, for example, "Linux Memory Allocation Limit on 32-bit Platform", from the UGS NX Nastran 5.0 Installation and Operations Guide, which briefly mentions the 1GB barrier.}

64bit + more ram, if you're using innodb then set your inndb_buffer_pool_size to about 70-75% of your total system ram. Tune cache sizes. If you're using recent versions of MySQL set your /tmp directory to use tmpfs (memory) which will allow MySQL to create temp tables in memory rather than on physical disk. Make sure MySQL is then configured to use /tmp for temp tables.

If you want to increase your memory, you have no choice, but to run a 64bit kernel. You can keep a 32bit userland if you want, but each process will be limited to a maximum of 2GB (maybe 3GB). You shouldn't need to reinstall everything, just a new kernel.

Most people are answering question #1, but let me chip in on question #2.

If you choose to run 64-bit Slackware, you only really have one choice: Slackware64. Slamd64 was an unofficial port of Slackware which has ceased to be necessary now that Slackware has an official 64-bit port. In terms of versions, you have the choice of the 13.0, 13.1, 13.37 and -current releases of Slackware64. Also note that 14.0 will likely be released soon, so you could also wait for that.