pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>
To: Tomas Vondra <tv@fuzzy.cz>
To: DFE <mimmopasticcio@gmail.com>
Cc: Niels Kristian Schjødt <nielskristian@autouncle.com>
Cc: pgsql-performance@postgresql.org list <pgsql-performance@postgresql.org>
Subject: Re: Optimal settings for RAID controller - optimized for writes
Date: Tue, 18 Feb 2014 10:23:09 +0900
Message-ID: <5302B5FD.10204@lab.ntt.co.jp> (raw)
In-Reply-To: <bc5e841fac96910a36a563e844dfb80a.squirrel@sq.gransy.com>
References: <D89BE95F-60D2-431B-A82D-53378392AAC3@autouncle.com>
	<CALqvQ1MRopjqc3W8Q_U061Lmm04Eip65cDNtfqB6mhj0wbA94g@mail.gmail.com>
	<bc5e841fac96910a36a563e844dfb80a.squirrel@sq.gransy.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

Hi,

I don't have PERC H710 raid controller, but I think he would like to know raid 
striping/chunk size or read/write cache ratio in writeback-cache setting is the 
best. I'd like to know it, too:)

Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center

(2014/02/18 0:54), Tomas Vondra wrote:
> The thing is, it's difficult to transfer these experiences without clear
> idea of the workloads.
>
> For example I wouldn't say 200 updates / second is a write-heavy workload.
> A single 15k drive should handle that just fine, assuming the data fit
> into RAM (which seems to be the case, but maybe I got that wrong).
>
> Niels, what amounts of data are we talking about? What is the total
> database size? How much data are you updating? Are those updates random,
> or are you updating a lot of data in a sequential manner? How did you
> determine UPDATEs are the bottleneck?
>
> Tomas
>
> On 17 Únor 2014, 16:29, DFE wrote:
>> Hi,
>> I configured a similar architecture some months ago and this is the best
>> choice after some pgbench and Bonnie++ tests.
>> Server: DELL R720d
>> CPU: dual Xeon 8-core
>> RAM: 32GB ECC
>> Controller PERC H710
>> Disks:
>> 2xSSD (MLC) Raid1 for Operating System (CentOS 6.4)
>> 4xSSD (SLC) Raid10 for WAL archive and a dedicated "fast tablespace",
>> where
>> we have most UPDATE actions (+ Hot spare).
>> 10xHDD 15kRPM Raid5 for "default tablespace" (optimized for space, instead
>> of Raid10)  (+ Hot spare).
>>
>> Our application have above 200 UPDATE /sec. (on the "fast tablespace") and
>> above 15GB per die of records (on the "default tablespace").
>>
>> After the testing phase I had the following conclusion:
>> 4xSSD (SLC) RAID 10 vs. 10xHDD RAID 5 have comparable I/O performance in
>> the sequential Read and Write, but much more performance on the Random
>> scan
>> (obviously!!), BUT as far I know the postgresql I/O processes are not
>> heavily involved in a random I/O, so at same price I will prefer to buy
>> 10xHDD instead of 4xSSD (SLC) using above 10x of available space at the
>> same price!!
>>
>> 10xHDD RAID 10 vs. 10xHDD RAID 5 : with Bonnie++ I noticed a very small
>> difference in I/O performance so I decided to use RAID 5 + a dedicated Hot
>> Spare instead of a RAID10.
>>
>> If I could go back,  I would have spent the money of the SLC in other
>> HDDs.






-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (20+ messages)  latest in thread

Message-ID: <5302B5FD.10204@lab.ntt.co.jp>
Permalink:  ../5302B5FD.10204@lab.ntt.co.jp/
Also on:    postgresql.org/message-id/5302B5FD.10204@lab.ntt.co.jp

 · 

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: kondo.mitsumasa@lab.ntt.co.jp, tv@fuzzy.cz, mimmopasticcio@gmail.com, nielskristian@autouncle.com
  Subject: Re: Optimal settings for RAID controller - optimized for writes
  In-Reply-To: <5302B5FD.10204@lab.ntt.co.jp>

* 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