Re: Optimal settings for RAID controller - optimized for writes

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Optimal settings for RAID controller - optimized for writes
Дата
Msg-id CAOR=d=048suxi+J+xw1E48PPsqCw81=-2tzF3bhgoOwSDcN07g@mail.gmail.com
обсуждение исходный текст
Ответ на Optimal settings for RAID controller - optimized for writes  (Niels Kristian Schjødt <nielskristian@autouncle.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why is the optimiser choosing the slower query, or, understanding explain analyze output
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: DB size and TABLE sizes don't seem to add up