Hi,
It is currently running on a 3GHz Xeon HT, 2GB RAM, dual 72GB disks running RAID 1. This server is a 1U without only 2 drive bays, so I have a potential issue with drive space. As a result, I will be moving the db server to a Dell 1650 with 3 146GB SCSI drives running RAID 0. System is a dual processor, 1.2GHz, with 4GB RAM.
Do you mean RAID0? You face total data loss when the first disk breaks - a 1.2GHz machine is not going to be young, so I assume neither are the disks - a recipe for disaster I think.
If your backup strategy is such that you can cope with total data loss and you are more interested in performance I believe you will get better performance by logical splitting of the database across multiple spindles rather than striping. For example if you put the write-ahead-log onto a spindle by itself you will get better performance than running everything on one jumbo RAID0 drive. Databases are usually sensitive to head latency rather than raw transfer rate. Dedicating one drive to the log (which must be written for each and every insert/update) minimizes the latency on writing the log. Is it perhaps an option to take the 146GB drives out of the 1650 and putting them into the Xeon machine? That might get you the best of both worlds (faster CPU, bigger hard disks, RAID1).
One final word or warning, whichever O/S you use HT doesn't always work well for postgres. It's hard to pin down exactly what happens, but on a P4 HT system (2.6 kernel again, PG 8.0) we found that we had some very odd performance problems that were hard to reproduce in the lab but occurred in the live environment a lot. Turning off HT made them go away.
Hope this helps, Robin
