Re: Disk configuration - Mailing list pgsql-performance

From Alex Turner
Subject Re: Disk configuration
Date
Msg-id 33c6269f05012008054e094a4f@mail.gmail.com
Whole thread Raw
In response to Re: Disk configuration  ("Benjamin Wragg" <bwragg@tpg.com.au>)
List pgsql-performance
I have never seen benchmarks for RAID 0+1.  Very few people use it
because it's not very fault tolerant, so I couldn't answer for sure.
I would imagine that RAID 0+1 could acheive better read throughput
because you could, in theory, read from each half of the mirror
independantly.  Write would be the same I would imagine because you
still have to write all data to all drives.  Thats my best guess.

Alex Turner
NetEconomist


On Thu, 20 Jan 2005 11:55:37 +1100, Benjamin Wragg <bwragg@tpg.com.au> wrote:
>
> Thanks. That sorts out all my questions regarding disk configuration. One
> more regarding RAID. Is RAID 1+0 and 0+1 essentially the same at a
> performance level?
>
> Thanks,
>
> Benjamin
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Alex Turner
> Sent: Thursday, 20 January 2005 2:53 AM
> To: Benjamin Wragg
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Disk configuration
>
> The primary goal is to reduce the number of seeks a disk or array has to
> perform.  Serial write throughput is much higher than random write
> throughput.  If you are performing very high volume throughput on a server
> that is doing multiple things, then it maybe advisable to have one partition
> for OS, one for postgresql binaries, one for xlog and one for table data (or
> multiple if you are PG8.0).  This is the ultimate configuration, but most
> people don't require this level of seperation.  If you do need this level of
> seperation, also bare in mind that table data writes are more likely to be
> random writes so you want an array that can sustain a high levels of IO/sec,
> so RAID 10 with 6 or more drives is ideal.  If you want fault tolerance,
> then RAID 1 for OS and postgresql binaries is a minimum, and I believe that
> xlog can also go on a RAID 1 unless you need more MB/sec.  Ultimately you
> will need to benchmark any configuration you build in order to determine if
> it's successfull and meets your needs.  This of course sucks, because you
> don't want to buy too much because it's a waste of $$s.
>
> What I can tell you is my own experience which is a database running with
> xlog, software and OS on a RAID 1, with Data partition running on
> 3 disk RAID 5 with a database of about 3 million rows total gets an insert
> speed of about 200 rows/sec on an average size table using a compaq proliant
> ML370 Dual Pentium 933 w/2G RAM.  Most of the DB is in RAM, so read times
> are very good with most queries returning sub second.
>
> Hope this helps at least a little
>
> Alex Turner
> NetEconomist
>
> On Wed, 19 Jan 2005 09:03:44 +1100, Benjamin Wragg <bwragg@tpg.com.au>
> wrote:
> >
> > I just wanted to bounce off the list the best way to configure disks
> > for a postgresql server. My gut feeling is as follows:
> >
> > Keep the OS and postgresql install on seperate disks to the postgresql
> > /data directory?
> > Is a single hard disk drive acceptable for the OS and postgresql
> > program, or will this create a bottle neck? Would a multi disk array
> > be more appropriate?
> >
> > Cheers,
> >
> > Benjamin Wragg
> >
> >
> > --
> >  No virus found in this outgoing message.
> >  Checked by AVG Anti-Virus.
> >  Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/01/2005
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.0 - Release Date: 17/01/2005
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 19/01/2005
>
>

pgsql-performance by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: PostgreSQL clustering VS MySQL clustering
Next
From: amrit@health2.moph.go.th
Date:
Subject: Re: PostgreSQL clustering VS MySQL clustering