Skip site navigation (1) Skip section navigation (2)

Re: new server I/O setup

From: "Fernando Hevia" <fhevia(at)ip-tel(dot)com(dot)ar>
To: "'Matthew Wakeling'" <matthew(at)flymine(dot)org>,"'Scott Marlowe'" <scott(dot)marlowe(at)gmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: new server I/O setup
Date: 2010-01-15 17:04:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance

> -----Mensaje original-----
> De: Matthew Wakeling [mailto:matthew(at)flymine(dot)org] 
> Enviado el: Viernes, 15 de Enero de 2010 08:21
> Para: Scott Marlowe
> CC: Fernando Hevia; pgsql-performance(at)postgresql(dot)org
> Asunto: Re: [PERFORM] new server I/O setup
> On Thu, 14 Jan 2010, Scott Marlowe wrote:
> >> I've just received this new server:
> >> 1 x XEON 5520 Quad Core w/ HT
> >> 8 GB RAM 1066 MHz
> >> 16 x SATA II Seagate Barracuda 7200.12 3ware 9650SE w/ 256MB BBU
> >>
> >> 2 discs in RAID 1 for OS + pg_xlog partitioned with ext2.
> >> 12 discs in RAID 10 for postgres data, sole partition with ext3.
> >> 2 spares
> >
> > I think your first choice is right.  I use the same basic 
> setup with 
> > 147G 15k5 SAS seagate drives and the pg_xlog / OS partition 
> is almost 
> > never close to the same level of utilization, according to 
> iostat, as 
> > the main 12 disk RAID-10 array is.  We may have to buy a 16 
> disk array 
> > to keep up with load, and it would be all main data 
> storage, and our 
> > pg_xlog main drive pair would be just fine.
> The benefits of splitting off a couple of discs for WAL are 
> dubious given the BBU cache, given that the cache will 
> convert the frequent fsyncs to sequential writes anyway. My 
> advice would be to test the difference. If the bottleneck is 
> random writes on the 12-disc array, then it may actually help 
> more to improve that to a 14-disc array instead.

I am new to the BBU cache benefit and I have a lot to experience and learn.
Hopefully I will have the time to tests both setups.
I was wondering if disabling the bbu cache on the RAID 1 array would make
any difference. All 256MB would be available for the random I/O on the RAID

> I'd also question whether you need two hot spares, with 
> RAID-10. Obviously that's a judgement call only you can make, 
> but you could consider whether it is sufficient to just have 
> a spare disc sitting on a shelf next to the server rather 
> than using up a slot in the server. Depends on how quickly 
> you can get to the server on failure, and how important the data is.

This is something I havent been able to make my mind since its very painful
to loose those 2 slots.
They could make for the dedicated pg_xlog RAID 1 Greg's suggesting.
Very tempting, but still think I will start safe for know and see what
happens later.

Thanks for your hindsight.


In response to


pgsql-performance by date

Next:From: Craig JamesDate: 2010-01-15 17:09:46
Subject: Re: a heavy duty operation on an "unused" table kills my server
Previous:From: Tom LaneDate: 2010-01-15 16:54:53
Subject: Re: New server to improve performance on our large and busy DB - advice? (v2)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group