Re: Optimal settings for RAID controller - optimized for writes

From: Michael Stone <mstone+postgres(at)mathom(dot)us>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimal settings for RAID controller - optimized for writes
Date: 2014-02-18 14:25:04
Message-ID: cb01d480-98a6-11e3-b0d7-00163eeb5320@msgid.mathom.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Feb 17, 2014 at 04:29:10PM +0100, DFE wrote:
>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).

That's bascially backwards. The WAL is basically a sequential write-only
workload, and there's generally no particular advantage to having it on
an SSD. Unless you've got a workload that's writing WAL faster than the
sequential write speed of your spinning disk array (fairly unusual).
Putting indexes on the SSD and the WAL on the spinning disk would
probably result in more bang for the buck.

One thing I've found to help performance in some workloads is to move
the xlog to a simple ext2 partition. There's no reason for that data to
be on a journaled fs, and isolating it can keep the synchronous xlog
operations from interfering with the async table operations. (E.g., it
enforces seperate per-filesystem queues, metadata flushes, etc.; note
that there will be essentially no metadata updates on the xlog if there
are sufficient log segments allocated.)

Mike Stone

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message David Wall 2014-02-18 17:48:50 Re: DB size and TABLE sizes don't seem to add up
Previous Message Heikki Linnakangas 2014-02-18 08:34:32 Re: DB size and TABLE sizes don't seem to add up