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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
