> -----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
Thanks for your hindsight.
In response to
pgsql-performance by date
|Next:||From: Craig James||Date: 2010-01-15 17:09:46|
|Subject: Re: a heavy duty operation on an "unused" table kills my
|Previous:||From: Tom Lane||Date: 2010-01-15 16:54:53|
|Subject: Re: New server to improve performance on our large and busy DB - advice? (v2) |