On Fri, 30 May 2003, Adam Witney wrote:
> 250,000 rows (5-10 numeric fields per row), processing the data (I may split
> this to a second box) and then writing back ~20,000 rows of data (2-3
> numeric fields per row).
Make sure and vacuum often and crank up your fsm values to be able to
reclaim lost disk space.
> 36Gb 10,000rpm Ultra 3 160 SCSI
> 36Gb 10,000rpm Ultra 3 160 SCSI
> 146Gb 10,000rpm U320 SCSI
> 146Gb 10,000rpm U320 SCSI
> 146Gb 10,000rpm U320 SCSI
>
> PERC 3/DC RAID Controller (128MB Cache)
If that box has a built in U320 controller or you can bypass the Perc,
give the Linux kernel level RAID1 and RAID5 drivers a try. On a dual CPU
box of that speed, they may well outrun many hardware controllers.
Contrary to popular opinion, software RAID is not slow in Linux.
> RAID1 for 2x 36Gb drives
> RAID5 for 3x 146Gb drives
You might wanna do something like go to all 146 gig drives, put a mirror
set on the first 20 or so gigs for the OS, and then use the remainder
(5x120gig or so ) to make your RAID5. The more drives in a RAID5 the
better, generally, up to about 8 or 12 as the optimal for most setups.
But that setup of a RAID1 and RAID5 set is fine as is.
By running software RAID you may be able to afford to upgrade the 36 gig
drives...
> Would it be better to have a dual 2.4GHz setup rather than a single 2.8GHz
> or would it not make much difference?
Yes it would. Linux servers running databases are much more responsive
with dual CPUs.
> Am I overdoing any particular component at the expense of another?
Maybe the RAID controller cost versus having more big hard drives.
