X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id DD53A52883 for ; Sun, 19 Jun 2005 01:58:53 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 44104-02 for ; Sun, 19 Jun 2005 04:58:48 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by svr1.postgresql.org (Postfix) with ESMTP id 7606C52871 for ; Sun, 19 Jun 2005 01:58:46 -0300 (ADT) Received: by wproxy.gmail.com with SMTP id 69so244404wra for ; Sat, 18 Jun 2005 21:58:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rvSrVOuriozcGF+dYXWOz63cVx1zgk1LeKHXsIUO+9PBWlYaVAF4rot7T3+0JwnTl5CC4VFIyBm8537i7kkZGP6qw2wuPdZiiFhaauzyLAftSC8V+XpHJvtLqSArVSHDZJRJDsbKXscu9j9KSeFp9HR04MlhatnhnUKingXvkQc= Received: by 10.54.50.77 with SMTP id x77mr2068225wrx; Sat, 18 Jun 2005 21:58:47 -0700 (PDT) Received: by 10.54.86.15 with HTTP; Sat, 18 Jun 2005 21:58:47 -0700 (PDT) Message-ID: <33c6269f050618215872479c8d@mail.gmail.com> Date: Sun, 19 Jun 2005 00:58:47 -0400 From: Alex Turner Reply-To: Alex Turner To: Jacques Caron Subject: Re: Multiple disks: RAID 5 or PG Cluster Cc: PFC , mudfoot@rawbw.com, pgsql-performance@postgresql.org In-Reply-To: <6.2.0.14.0.20050618181239.0446d7a8@pop.interactivemediafactory.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7342_25943775.1119157127132" References: <7a1914222f313b7c5e88bedb8a662f12@implements.be> <1119040721.42b334d1c3ec9@webmail.rawbw.com> <6.2.0.14.0.20050618181239.0446d7a8@pop.interactivemediafactory.net> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.358 tagged_above=0 required=5 tests=AWL, HTML_20_30, HTML_MESSAGE, RCVD_BY_IP X-Spam-Level: X-Archive-Number: 200506/362 X-Sequence-Number: 12999 ------=_Part_7342_25943775.1119157127132 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Of course these numbers are not true as soon as you exceed the stripe size= =20 for a read operation, which is often only 128k. Typically a stripe of=20 mirrors will not read from seperate halves of the mirrors either, so RAID 1= 0=20 is only N/2 best case in my experience, Raid 0+1 is a mirror of stripes and= =20 will read from independant halves, but gives worse redundancy. Alex Turner NetEconomist On 6/18/05, Jacques Caron wrote: >=20 > Hi, >=20 > At 18:00 18/06/2005, PFC wrote: > > I don't know what I'm talking about, but wouldn't mirorring be > > faster > >than striping for random reads like you often get on a database ? (ie.= =20 > the > >reads can be dispatched to any disk) ? (or course, not for writes, but i= f > >you won't use fsync, random writes should be reduced no ?) >=20 > Roughly, for random reads, the performance (in terms of operations/s) > compared to a single disk setup, with N being the number of drives, is: >=20 > RAID 0 (striping): > - read =3D N > - write =3D N > - capacity =3D N > - redundancy =3D 0 >=20 > RAID 1 (mirroring, N=3D2): > - read =3D N > - write =3D 1 > - capacity =3D 1 > - redundancy =3D 1 >=20 > RAID 5 (striping + parity, N>=3D3) > - read =3D N-1 > - write =3D 1/2 > - capacity =3D N-1 > - redundancy =3D 1 >=20 > RAID 10 (mirroring + striping, N=3D2n, N>=3D4) > - read =3D N > - write =3D N/2 > - capacity =3D N/2 > - redundancy < N/2 >=20 > So depending on your app, i.e. your read/write ratio, how much data can b= e > cached, whether the data is important or not, how much data you have, etc= , > one or the other option might be better. >=20 > Jacques. >=20 >=20 >=20 > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if you= r > joining column's datatypes do not match > ------=_Part_7342_25943775.1119157127132 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Of course these numbers are not true as soon as you exceed the stripe size for a read operation, which is often only 128k.  Typically a stripe of mirrors will not read from seperate halves of the mirrors either, so RAID 10 is only N/2 best case in my experience, Raid 0+1 is a mirror of stripes and will read from independant halves, but gives worse redundancy.

Alex Turner
NetEconomist

On 6/18/05, Jacques Caron <jc@directinfos.com> wrote:
Hi,

At 18:00 18/06/2005, PFC wrote:
>    &= nbsp;    I don't know what I'm talking about, but wouldn't m= irorring be
> faster
>than striping for random reads like you o= ften get on a database ? (ie. the
>reads can be dispatched to any disk) ? (or course, not for writes, but = if
>you won't use fsync, random writes should be reduced no ?)
Roughly, for random reads, the performance (in terms of operations/s)
compared to a single disk setup, with N being the number of drives, is:
=
RAID 0 (striping):
- read =3D N
- write =3D N
- capacity =3D N=
- redundancy =3D 0

RAID 1 (mirroring, N=3D2):
- read =3D N- write =3D 1
- capacity =3D 1
- redundancy =3D 1

RAID 5 (striping + parity= , N>=3D3)
- read =3D N-1
- write =3D 1/2
- capacity =3D N-1
= - redundancy =3D 1

RAID 10 (mirroring + striping, N=3D2n, N>=3D4)=
- read =3D N
- write =3D N/2
- capacity =3D N/2
- redundancy < N/2

S= o depending on your app, i.e. your read/write ratio, how much data can becached, whether the data is important or not, how much data you have, etc= ,
one or the other option might be better.

Jacques.


---------------------------(end of broadcast)---------------------------TIP 9: the planner will ignore your desire to choose an index scan if you= r
      joining column's datatypes do not m= atch

------=_Part_7342_25943775.1119157127132--