Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlbj-0004Ba-Th for pgsql-performance@arkaria.postgresql.org; Tue, 18 Feb 2014 14:25:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WFlbj-0007vl-AM for pgsql-performance@arkaria.postgresql.org; Tue, 18 Feb 2014 14:25:11 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlbh-0007vX-Si for pgsql-performance@postgresql.org; Tue, 18 Feb 2014 14:25:10 +0000 Received: from harad.mathom.us ([54.218.24.45]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WFlbe-0007Nl-Bi for pgsql-performance@postgresql.org; Tue, 18 Feb 2014 14:25:08 +0000 Received: from osgiliath.mathom.us (osgiliath.mathom.us [IPv6:2001:4830:1614:2341::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by harad.mathom.us (Postfix) with ESMTPS id 45CDC401F3 for ; Tue, 18 Feb 2014 14:25:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mathom.us; s=mail; t=1392733504; bh=+eEVGr5BEJ+bA41WXjiThlIizSFZ7o3465pJiiSeTEY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=t1Sprkz7FOgNistKkSXsURN3LJ0a4a6PuTG+jitnffNRP7w0CezP6sgFLcpqWYMcu yTluYxfRWN6s6jkKRLa8mR3u/bWwa+AvbZGGa7DTdvGO9gEWLAC+sku4mgN6bQ7onH NH5GZxLB1XWt7iJFX66F3yrs66xUs+yESlRkdvJ4= Received: from localhost (localhost [127.0.0.1]) by osgiliath.mathom.us (Postfix) with ESMTP id 1F58B6E663 for ; Tue, 18 Feb 2014 09:25:05 -0500 (EST) Received: from osgiliath.mathom.us ([127.0.0.1]) by localhost (osgiliath.mathom.us [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Qq-E4RZAaP82 for ; Tue, 18 Feb 2014 09:25:04 -0500 (EST) Received: by osgiliath.mathom.us (Postfix, from userid 1000) id E1F046EA88; Tue, 18 Feb 2014 09:25:04 -0500 (EST) Date: Tue, 18 Feb 2014 09:25:04 -0500 From: Michael Stone To: pgsql-performance@postgresql.org Subject: Re: Optimal settings for RAID controller - optimized for writes Message-ID: Mail-Followup-To: pgsql-performance@postgresql.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Pgp-Fingerprint: 02D5 315F F11F 1861 860E 1E02 F61A ACDC FA11 FFDE User-Agent: Mutt/1.5.21 (2010-09-15) X-Pg-Spam-Score: -4.9 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance