[NTLUG:Discuss] Dell Server with PERC RAID
Kelledin
kelledin+NTLUG at skarpsey.dyndns.org
Thu Sep 25 15:48:45 CDT 2003
On Thursday 25 September 2003 01:01 pm, Stuart Johnston wrote:
> I posted a question a while back asking for recommendations on
> inexpensive servers for Linux. The most popular suggestion
> seemed to be Dell. I'm trying to overcome my reluctance to
> use Dell due to past negative experience with their desktops
> (-understatement-) and we now have two refurb Dell PowerEdge
> 2450s - Dual P3 700, PERC3/Si - RAID U160 SCSI, 2GB RAM.
>
> So far, it seems pretty good. It sometimes seems a little
> slower than I had expected though, particularly the disk
> access. It has 4 SCSI disks running RAID 5. At times, it
> seems slower than our development machine which has a single
> IDE drive. This is basically my first experience setting up a
> RAID system so I may be missing something simple.
Well, RAID5 is in some cases actually slower than a single drive,
particularly in write speed. Read speed is usually faster as
long as the RAID controller doesn't bottleneck it, and none of
your drives are faulty. Also, synthetic tests for sustained
transfer rate--WinBench raw disk transfer tests, hdparm -t, and
Sandra--almost always output lower scores with RAID arrays than
with single drives (even RAID0 arrays). StorageReview.com
discovered this years back, and I don't remember them ever
figuring out why--they just switched to IOMeter, which produced
good and sensible results.
A couple of things that help a LOT with RAID5 are fast hardware
XOR and lots of cache memory (both on the RAID controller). I
have 32MB of cache SIMMs on my DPT SmartRAID V controller, and
I'm considering adding another 32MB to bring the thing up to max
cache capacity--especially since the memory is so cheap now.
Beyond that, I don't know what would apply to your particular
RAID controller. I'm a DPT (now Adaptec) man myself.
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
More information about the Discuss
mailing list