On Sun, 31 Oct 1999, Shoggoth wrote:
Hi,
> My RAID is like this :
>
> IDE0 ---- >hda1 (170mb)
> |-->hdb1 (Seagate 210) |
> IDE1----->hdc1 (Seagate 210) | -> md0
> |-->hdd1 (Conner 210) |
>
> on a 486DX2-66 with Debian 2.1. The two IDE are in one ISA card.
>
> The cuestion is : Should i install every HD in his own IDE controler
> and became master ? (I'm talking of 4 ISA cards) or the bus is just so slow
> that this makes no difference in perfomarce terms?
It won't probably make a difference in performance due to its slow
processor/bus/etc, but you'll gain some side advantages: On a failure
event of any of the master/slave disks on a same IDE port, chances are
that both will become unusable, including the one that is OK. So you'd
better using disks only as masters...
An advice: never trust 486 BIOSes/integrated controllers for
secondary IDE ports...
> The power supply is 230W : Am i in danger of power supply failure?
That doesn't specify the +/- 5v lines power or 12v line power,
look at each drive power consuption specification (take into account
what's the max. peak power consumption per voltage line). Some power
supplies have a sticker with those numbers also...
Newer disks have lower power consumption requirements, but I'd
guess you're just in the top border...
> And finaly : Are there some studies on performace gains in SQL
> servers over a RAID? Particulary a MySQL working against an php-enabled
> Apache web server
Using RAID with SQL engines needs a different approach. It depends
also on what you're looking for. If you're looking for performance, the
first thing that improves things are addecuate table/indexes design. Once
achieved this, it depends on the SQL engine, I'd speak for MySQL.
Assume you have 6 tables, A, B, C, D, E and F, and 4 disks. To start, you
have to analyze your application behaviour and table use, then try to put
every potential bottleneck file on different disks/volumes, i.e. if you
have two tables that are going to be used pretty often on a concurrent
manner (A and E for example), put each datafile (*.ISM) on different
disks, and their index files (*.ISD) on separate disks/volumes also; then
distribute the rest of data and index files amongs the disks, trying to
put data/index on separate disks:
That way:
disk1: A.ISM, B.ISM, C.ISM
disk2: A.ISD, B.ISD, C.ISD
disk3: D.ISM, E.ISM, F.ISM
disk4: D.ISD, E.ISD, F.ISD
You get the idea: try to distribute simultaneous accesses.
You can use symlinks to link the files to
/var/lib/mysql/whateverDB/file.{ISD,ISM}.
I've talked about disks till now. Extrapolating this to raid
volumes usually imply needing more disks (as a rule of thumb, the double).
But with a clever distribution (clever -> knowing exactly how your
application is going to behave) you can achieve the same.
- I'd use raid level 1 sets for disk1 and disk3. You won't probably
achieve better performance, (due to your slow machine) but you'll have
redundancy i.e.:
now disk1 becomes md0 (hda1,hdb1)
and disk3 -> md2 (hdc1,hdd1)
- and raid level 0 sets for disk2 and disk4, as you don't care about
redundancy w/ index files (you can easily recreate them). I don't know if
using raid 0 in that machine will give more performance, (although you'll
benefit for larger storage capacity coupling those small disks) i'd bet
no... just trying to generalise for other potential readers...
The raid set:
disk2 -> md1 (hdc2,hdd2)
disk4 -> md3 (hda2,hdb2)
this way, you aren't fully avoiding bottlenecks, but you don't
need 8 disks...
As a side note, I'd only use raid on your configuration for redundancy
purposes. Yoy'd probably get worst numbers using it that using simple
partitions. But you're worried abouth those (oldies?) disks future life,
aren't you? :)
> Thanks you for your patience , and greetings to pukka (we miss you in
> #linux , man)
:) hehe...
cheers,
*****---(*)---**********************************************---------->
Francisco J. Montilla System & Network administrator
[EMAIL PROTECTED] irc: pukka Seville Spain
INSFLUG (LiNUX) Coordinator: www.insflug.org - ftp.insflug.org
