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

[Gerry Creager N5JXS]

One problem with RAID, only partially mediated by SCSI, is that nor all 
hardware controllers are created equally.  It's much worse in parallel 
ATA implementations, bad enough in SATA implenentations, and still 
problemmatical in SCSI.  One should carefully choose ones controller and 
perform due diligence in selecting one.  A big name isn't good enough, 
as not all of Adaptec's controllers are real hardware RAID.  In the ATA 
world, I no longer buy anything save 3Ware or LSI, as I've contributed 
to the others, who claim hardware RAID but performance suggests they 
really aren't... and that their implementation of s/w RAID is 
significantly poorer than than the stock Linux or BSD implementations of 
s/w RAID.

scott at opentrac.org wrote:

>>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.

Yup, that's my evaluation, too...

However: Steve's very comfortable with MySQL and it's done all right so 
far.  I intend to host whatever he wants and go on from there.

gerry
-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843