Re: Optimal settings for RAID controller - optimized for writes - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: Optimal settings for RAID controller - optimized for writes
Date
Msg-id CAOR=d=048suxi+J+xw1E48PPsqCw81=-2tzF3bhgoOwSDcN07g@mail.gmail.com
Whole thread Raw
In response to Optimal settings for RAID controller - optimized for writes  (Niels Kristian Schjødt <nielskristian@autouncle.com>)
List pgsql-performance
On Mon, Feb 17, 2014 at 8:03 AM, Niels Kristian Schjødt
<nielskristian@autouncle.com> wrote:
> Hi,
>
> I'm kind of a noob when it comes to setting up RAID controllers and tweaking them so I need some advice here.
>
> I'm just about to setup my newly rented DELL R720 12. gen server. It's running a single Intel Xeon E5-2620 v.2
processorand 64GB ECC ram. I have installed 8 300GB SSDs in it. It has an PERC H710 raid controller (Based on the LSI
SAS2208 dual core ROC). 
>
> Now my database should be optimized for writing. UPDATEs are by far my biggest bottleneck.
>
> Firstly: Should I just put all 8 drives in one single RAID 10 array, or would it be better to have the 6 of them in
oneRAID 10 array, and then the remaining two in a separate RAID 1 array e.g. for having WAL log dir on it's own drives? 
>
> Secondly: Now what settings should I pay attention to when setting this up, if I wan't it to have optimal write
performance(cache behavior, write back etc.)? 

Pick a base configuration that's the simplest, i.e. all 8 in a
RAID-10. Benchmark it to get a baseline, using a load similar to your
own. You can use pgbench's ability to run scripts to make some pretty
realistic benchmarks. Once you've got your baseline then start
experimenting. If you can't prove that moving two drives to RAID-1 for
xlog makes it faster then don't do it.

Recently I was testing MCL FusionIO cards (1.2TB) and no matter how I
sliced things up, one big partition was just as fast as or faster than
any other configuration (separate spinners for xlog, etc) I could come
up with. On this machine sequential IO to a RAID-1 pair of those was
~1GB/s. Random access during various pgbench runs was limited to
~200MB/s random throughput. Moving half of that (pg_xlog) onto other
media didn't make things any faster and just made setup more
complicated. I'll be testing 6x600GB SSDs in the next few weeks under
an LSI card, and we'll likely have a spinning drive RAID-1 for pg_xlog
there, at least to compare. If you want I can post what I see from
that benchmark next week etc.

So how many updates / second do you need to push through this thing?


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is the optimiser choosing the slower query, or, understanding explain analyze output
Next
From: Heikki Linnakangas
Date:
Subject: Re: DB size and TABLE sizes don't seem to add up