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