Behind AnandTech - The Search for the Perfect Serversby Anand Lal Shimpi on August 23, 2000 12:00 PM EST
- Posted in
- IT Computing
Database Server Number 1
As we continued our learning process, it quickly became evident that our Enterprise 250 server was in desperate need of an upgrade. Not memory, and not CPU wise, rather our database server was suffering from I/O bottleneck problems, the worst type of problem you can have with a database server other than having one that's not operational. With only a single SCSI drive in the DB server, the web server was left in a situation where, under load, the disk performance of the DB box was slowing down the amount of time it would take to serve a page.
After weighing our options, and realizing that it was more cost effective for us to put together a new x86-NT system than keep on upgrading the Sun box, we began constructing a new DB box to alleviate our I/O bottleneck problems.
The new DB box used the same Dual Pentium III Xeon 500's as the web box, each with 1MB of L2 cache running at the core clock speed. Having a large cache is more important to a DB box than having faster clocked CPUs, in most cases that is, and in ours this definitely held true.
We used the same Tyan Thunder X board from the first server, and outfitted it with 1GB of ECC PC100 SDRAM, provided by Azzo.com.
The most important consideration for the DB server was, naturally, its disk I/O performance. While we could have used a single Ultra2 SCSI drive, capable of bursting at up to 80MB/s, we'd still be limiting ourselves in the long run. Instead we picked up an Adaptec AAA-133U2 Ultra2 SCSI RAID card. The AAA-133U2 features three independent Ultra2 channels which would work perfectly with the plans we had for the DB box which was to setup a RAID 5 array with three IBM Ultrastar 9LZX drives.
Add in an extra SCSI drive for the boot device operating off of the motherboard's integrated SCSI controller and our DB box was ready for action.
Since we were migrating away from Sun, we also moved DB software from Oracle to SQL7. There were no problems with Oracle, it was just easier to find developers for SQL7 and the cost of running the latter was noticeably less than Oracle.
Upon doing this upgrade, we also made sure that all of the servers had dual NICs, one for all internal DB traffic and one for all external (net) traffic.