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.

  • which DB engine are you using? – Chopper3 Jun 15 '09 at 11:45
  • Slackware? Who still uses slackware and why? – niXar Jun 15 '09 at 13:15
  • @Chopper3: FirebirdSQL – Milan Babuškov Jun 16 '09 at 9:22
  • @Milan: Just my $0.02, I used to run an all Slack infrastructure, too. I migrated to CentOS because even though I loved Slack dearly and used it for 9+ years, it just wouldn't scale. When you get a chance, you might look into migrating your enterprise stuff away too. Just a suggestion. – Matt Simmons Jun 16 '09 at 20:54
  • @Matt: thanks. I'm already using CentOS for Internet servers. However, I find Slackware easier to setup and maintain for intranet/database server usage. – Milan Babuškov Jun 17 '09 at 8:00

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.
  • Thanks for detailed reply. Write perfomance is not important here. The databases are mostly read-from and largest database size is 3GB and growning. Being able to cache it (entirely if possible) in RAM is one of the main reasons to increase memory because it significantly effects performance. – Milan Babuškov Jun 16 '09 at 9:43
  • 1
    Milan, if you largest DB is 3GiB and growing, you most definitely have to go for a 64-bit OS, so the DB process can grow beyond 3GiB in memory. – wzzrd Jun 16 '09 at 13:05
  • 1
    I don't think that's strictly necessary, but having enough RAM to cache the entire database working set will be a definite win. – ConcernedOfTunbridgeWells Feb 22 '10 at 15:05

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.


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.

  • 2
    In general, if any process is going to need more that 4GB then you'll need 64bit. – Andrew Williams Jun 15 '09 at 12:09
  • Actually, if you need more than 3GiB in userspace for a program, you need 64-bit. Or to rephrase this: if you do not have compelling reasons to stay with 32-bit in such a situation, you are probably better off with a 64-bit system. Otoh, I can think of scenarios where the 3GiB limit is actually a blessing. – wzzrd Jun 15 '09 at 13:04

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.

  • I'm actually using Firebird, not MySQL, and I do allocate 2.5GB or RAM for the cache/sort space. – Milan Babuškov Jun 22 '09 at 17:34

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.

  • 1
    Nearly every x86 CPU manufactured supports PAE, which allows for > 4G of physical RAM with a 32-bit OS. – James Cape Jun 15 '09 at 12:03
  • but we don't know if his DB is PAE-aware yet – Chopper3 Jun 15 '09 at 12:07
  • 2
    Yes, you can use PAE, but supporting more than 1GB in 32bit is a hack. Supporting more than 4GB is a massive hack. Using a 64bit kernel with an existing 32bit userland gives you the expanded memory address range without the disruption of reinstalling. – David Pashley Jun 15 '09 at 12:22
  • @Chopper3: userspace processes aren't "PAE-aware" or not. 32-bit processes can access 4GB each (2/2 or 3/1); it's the kernel that can manage more than 4GB if it handles PAE or just 4GB in total if not. – Javier Jun 15 '09 at 16:50

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.