Re: Scaling with memory & disk planning

From: terry(at)greatgulfhomes(dot)com
To: "'Scott Marlowe'" <scott(dot)marlowe(at)ihs(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: Scaling with memory & disk planning
Date: 2002-05-30 22:12:00
Message-ID: 000001c20827$05e5fae0$2766f30a@development.greatgulfhomes.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

What is RAID1 with > 2 drives???

Terry Fielder
Network Engineer
Great Gulf Homes / Ashton Woods Homes
terry(at)greatgulfhomes(dot)com

> -----Original Message-----
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org]On Behalf Of Scott Marlowe
> Sent: Thursday, May 30, 2002 5:45 PM
> To: terry(at)greatgulfhomes(dot)com
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Scaling with memory & disk planning
>
>
> On Thu, 30 May 2002 terry(at)greatgulfhomes(dot)com wrote:
>
> I agree with ALMOST everything you say, but have a few minor
> nits to pick.
> nothing personal, just my own experience on RAID testing and such.
>
> > In RAID5, the most efficient solution, every 1 byte written
> requires LESS
> > then 1 byte written for the CRC.
>
> This isn't true for any RAID 5 implementation I'm familiar with. The
> parity stripe is exactly the same size as the data stripes it
> shares space
> with. But this isn't a real important point, since most RAID
> arrays write
> 8k to 128k at a time. Note that it's not CRC (Cyclic
> Redunancy Check)
> that gets written, but straight XOR, hence no space savings.
>
> > Roughly (depending on implementation,
> > number of disks) every 3 bytes written requires 4 bytes of disk IO.
> >
> > RAID5 is the fastest from an algorithm, standpoint. There
> is some gotchas,
> > RAID5 implemented by hardware is faster the RAID5
> implemented by OS, simply
> > because the controller on the SCSI card acts like a
> parallel processor.
>
> This is most definitely not always true, even given equal
> hardware specs
> (i.e. number and type of drives / interfaces all the same).
>
> My old AMI Megaraid card with 3 Ultra Wide SCSI ports can
> generate 64 Megs
> of parity data per second. My Celeron 1.1GHz machine can generate
> 2584 Megs of parity data per second. The load on the CPU under VERY
> heavy reads and writes is about 0.3% cpu, and the max
> throughput on reads
> on a RAID array of 4 VERY old (non-ultra non-wide 7200RPM) 2
> Gig drives is
> about 33 Megs a second read speed.
>
> Same setup with 7200 4 Gig Ultra narrow drives on an AMI raid
> can read at
> about 14 Megabytes a second.
>
> The most important part of fast RAID is the drives first, interface
> second, and hardware versus software raid last. While it was
> often true
> in the dark past of 33 Megahertz CPUs and such that hardware raid was
> always faster, it is often much better to spend the extra
> money a RAID
> controller would cost you and just buy more drives or cheaper
> controllers
> or memory or CPUs.
>
> Generally speaking, I've found RAID5 with 4 or fewer drives
> to be about
> even with RAID1, while RAID5 with 6 or more drives quickly starts to
> outrun a two drive mirror set. This is especially true under heavy
> parallel access.
>
> On a subject no one's mentioned yet, >2 drives in a RAID1 setup.
>
> I've done some testing with >2 drives in a mirror (NOT 1+0 or
> 0+1, just
> RAID1 with >2 drives) under Linux, and found that if you are
> doing 90%
> reads then it's also a good solution, but for most real world
> database
> apps, it doesn't really help a lot.
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo(at)postgresql(dot)org
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2002-05-30 22:34:23 Re: Scaling with memory & disk planning
Previous Message Shaun Thomas 2002-05-30 22:01:10 Re: horrendous query challenge :-)