pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Merlin Moncure <mmoncure@gmail.com>
To: Francisco Reyes <lists@stringsutils.com>
Cc: PFC <lists@peufeu.com>
Cc: Pgsql performance <pgsql-performance@postgresql.org>
Subject: Re: RAID controllers for Postgresql on large setups
Date: Tue, 13 May 2008 08:07:22 -0400
Message-ID: <b42b73150805130507u9636a9fpcbfc7901fa7cfbdb@mail.gmail.com> (raw)
In-Reply-To: <cone.1210680025.806890.27271.1000@zoraida.natserv.net>
References: <cone.1210644243.416947.84940.1000@zoraida.natserv.net>
	<op.ua26u3iacigqcu@apollo13.peufeu.com>
	<cone.1210680025.806890.27271.1000@zoraida.natserv.net>

On Tue, May 13, 2008 at 8:00 AM, Francisco Reyes <lists@stringsutils.com> wrote:
> PFC writes:
>
>
> >        You say that like you don't mind having PCI in a server whose job
> is to  perform massive query over large data sets.
> >
>
>  I am in my 4th week at a new job. Trying to figure what I am working with.
>  From what I see I will likely get as much improvement from new hardware as
> from re-doing some of the database design. Can't get everything done at
> once, not to mention I have to redo one machine sooner rather than later so
> I need to prioritize.
>
>
>
> > In fact for bulk IO a box with 2 SATA drives would be just as fast as
> your monster RAID, lol.
> >
>
>  I am working on setting up a standard test based on the type of operations
> that the company does. This will give me a beter idea. Specially I will work
> with the developers to make sure the queries I create for the benchmark are
> representative of the workload.
>
>
>
> > Adding more drives will help random reads/writes but do nothing for
> throughput since the tiny PCI pipe is choking.
> >
>
>  Understood, but right now I have to use the hardware they already have.
> Just trying to make the most of it. I believe another server is due in some
> months so then I can better plan.
>
>  In your opinion if we get a new machine with PCI-e, at how many spindles
> will the  SCSI random access superiority start to be less notable? Specially
> given the low number of connections we usually have running against these
> machines.
>
>
>
> >        However RAID5 will choke and burn on small random writes, which
> will come   from UPDATing random rows in a large table, updating indexes,
> etc. Since  you are doing this apparently, RAID5 is therefore NOT advised !
> >
>
>  I thought I read a while back in this list that as the number of drives
> increased that RAID 5 was less bad. Say an external enclosure with 20+
> drives.

maybe, but I don't think very many people run that many drives in a
raid 5 configuration...too dangerous.   with 20 drives in a single
volume, you need to be running raid 10 or raid 6.  20 drive raid 50 is
pushing it as well..I'd at least want a hot spare.

merlin



view thread (16+ messages)  latest in thread

Message-ID: <b42b73150805130507u9636a9fpcbfc7901fa7cfbdb@mail.gmail.com>
Permalink:  ../b42b73150805130507u9636a9fpcbfc7901fa7cfbdb@mail.gmail.com/
Also on:    postgresql.org/message-id/b42b73150805130507u9636a9fpcbfc7901fa7cfbdb@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: mmoncure@gmail.com, lists@stringsutils.com, lists@peufeu.com
  Subject: Re: RAID controllers for Postgresql on large setups
  In-Reply-To: <b42b73150805130507u9636a9fpcbfc7901fa7cfbdb@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox