Linux provides a very solid platform to run 32 and 64 bit database servers. The two most popular open database packages are MySQL and PostgreSQL but Firebird is gaining in popularity. When building an open source database solution, well any database solution, one must consider a number of factors. Here's what we think you should think.
Server Hardware
Database servers must have plenty of horsepower to execute queries in a reasonable time under moderate load. This translates into a requirement to hold open socket connections, volumes of network traffic, intelligent queries and transactions and demanding disc reads/writes. At the time of this original writing a moderate system (=$4000) was dual-processor and 2 or 4GiB of RAM with a pair of 180 SCSI discs. In 2008 systems with eight-cores and more than 16GiB of RAM are common, fast-SATA provides a cost effective alternative to SCSI.
When choosing a processor our choice is to gain (in this order) 1) more cores, 2) more speed, 3) larger registers. When evaluating the price our focus is on getting as much parallellisation as possible. Any modern RDMBS will take advantage of this. Fast is always good but, we think parallel is more important. As the cost of true 64bit architectures lowers and the software stabalises these larger registers could easily become the primary processor choice.
Physical Memory (RAM) are directly related to the number of queries and connections possible. More is better, more more more. Just think more. Is 16GiB good? Yes. Well should I get 32GiB? OF COURSE! More is better.
Databases have a tendency to consume lots of Physical Storage on the hard disc.
To achieve good performance this input/output must be fast.
Everyone also wants redundancy on the discs, incase of failure you won't loose data.
Many papers on the internet document the performance of hardware based RAID 1 has the best performance/cost.
More complex RAID systems are coming online including RAID 10 which may be promising.
Any of the systems that require striping+parity (RAID 5) will be slower on writes than simpler RAID options.
Keep this in mind and spend the extra money on hardware RAID though, we have seen some running with Linux md
.
For reference in 2002 we thought that a four-core 2.5GHz with 4GiB of RAM was good. Then in 2005 we were using an eight-core 3GHz with 16GiB of RAM and RAID1 SCSI-320 15K In Oct 2008 we like eight-core with 32GiB and RAID1 on fast SATA or SCSI.
Server Software
Database servers should be configured to do nothing else. Other programs on the system will compete with the chosed RDBMS for resources and could slow it down. Depending on how you tune your system this could be pretty light weight. As an example our current database server, in Oct 2008, our primary database server is running only eight additional processes. We have: agetty(2), fcron, ntpd(2), ssh, syslog-ng and udevd which consume very little CPU and only 10MiB of RAM combined. Tune what processes your system runs!
Other things to configure / check
- Disable worthless cron jobs! Getting a slow query because updatedb is running sucks.
- Reduce disc I/O by sending syslog to an centralised server, send database logs to syslog.
- Maybe able to turn off log-rotate?
- Configure some type for RDD tool or SNMP monitoring and create graphs of system load!