[aprssig] Re: More on the findU server issue...

[scott at opentrac.org]

> Sorry if it has been mentioned before, but are you using 
> stand-along hard drives for findu.com, or are they set up as 
> a RAID? For most people, RAID 1 for would be more important 
> because of the redundancy it would provide, but I wonder if 
> RAID 0, 2, 3, 4, 5 or 6 (dunno which would be best for 
> findu.com) would be better because of the faster access 
> times... or are you already using RAID 0+1 so you have both 
> mirroring and striping?

Depending on the database configuration (again, I'm not a MySQL guy) RAID's
not always the answer.  I used to run a big database on an old AlphaServer
cluster that had absolutely no RAID, just slow SCSI2 drives over DSSI, but
it had complete redundancy and good performance.  When you're writing to a
database and it's got to update multiple tables and indexes, it's faster to
have each table or index on its own drive than to use those same drives in a
RAID because of the reduced seek overhead.  Of course, if you've got the
bucks you can just devote a RAID to each tablespace rather than a single
drive!  I'm still running that old database, but it's now on a
multi-terabyte fiber channel SAN with a couple of RAID 10 groups allocated
to it.  I could use more drives to optimize it further, but the hardware is
so much faster than the old stuff that there's no point.  Who cares if the
query runs in 3 msec instead of 15 msec when it takes the Java front end 500
msec to get around to displaying it?  When the Java front end isn't busy
crashing, that is...

Blindly throwing expensive hardware at a performance problem without
understanding the bottlenecks isn't the solution.  Well, it can be, but it's
an expensive solution!  Unfortunately I think that in this case MySQL just
isn't that sophisticated and it'll need some fast hardware behind it.

Scott
N1VG