Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UfEkF-0006Tl-Cv for pgsql-performance@arkaria.postgresql.org; Wed, 22 May 2013 19:30:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UfEkE-0001sJ-Tt for pgsql-performance@arkaria.postgresql.org; Wed, 22 May 2013 19:30:42 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UfEkE-0001sE-3r for pgsql-performance@postgresql.org; Wed, 22 May 2013 19:30:42 +0000 Received: from moutng.kundenserver.de ([212.227.126.171]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UfEkB-0003Vw-9G for pgsql-performance@postgresql.org; Wed, 22 May 2013 19:30:41 +0000 Received: from [192.168.1.110] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MT3vW-1V5Bab2jaA-00SEgN; Wed, 22 May 2013 21:30:32 +0200 Message-ID: <519D1CD6.2080607@2ndQuadrant.com> Date: Wed, 22 May 2013 15:30:30 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Joshua D. Drake" CC: sthomas@optionshouse.com, Merlin Moncure , Tomas Vondra , pgsql-performance@postgresql.org Subject: Re: Reliability with RAID 10 SSD and Streaming Replication References: <51957499.6050905@fuzzy.cz> <519991EB.8010208@2ndQuadrant.com> <519A8E29.60702@fuzzy.cz> <519C0EFD.9080002@2ndQuadrant.com> <519CF8CC.1030204@optionshouse.com> <519D0921.9080807@2ndQuadrant.com> <519D174A.4050703@commandprompt.com> In-Reply-To: <519D174A.4050703@commandprompt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:g5tO1mWsXYNIIyt5dnLuE8BlzRPt7zvNC+5C6snvsHv 1EmVcPhbor3G982pgfpG2CKjctKogLy8KuyHu3niFvdVAowZP7 GydVG9upfq+K+IW89H5iXcpCzw+XE3KJZ2xLKTx2bg3cOI8nc+ MQVV8onf2kEgEPBjYYr7iimOhqhDeoGu9e0iDWOKTCDOPxMwZF jfdg2OuGdNKivv6PYWIkjw6W22/pbWSAxjwY3v/QlvjdORVOjB gXRT78jCwGlIHvlcDVgEN8Atzjz9gPgJwA2IrnUajitJpvuHIC SahEQL1HiuTh1DCCNBjvs1jZOyzWFIZDSfBlqcyR8UXmDUsW7J P4QsLNHcdgVcvkj9BbdQ= X-Pg-Spam-Score: 0.8 (/) 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 5/22/13 3:06 PM, Joshua D. Drake wrote: > Greg, can you elaborate on the SSD + Xlog issue? What type of burn > through are we talking about? You're burning through flash cells at a multiple of the total WAL write volume. The system I gave iostat snapshots from upthread (with the Intel 710 hitting its limit) archives about 1TB of WAL each week. The actual amount of WAL written in terms of erased flash blocks is even higher though, because sometimes the flash is hit with partial page writes. The write amplification of WAL is much worse than the main database. I gave a rough intro to this on the Intel drives at http://blog.2ndquadrant.com/intel_ssds_lifetime_and_the_32/ and there's a nice "Write endurance" table at http://www.tomshardware.com/reviews/ssd-710-enterprise-x25-e,3038-2.html The cheapest of the Intel SSDs I have here only guarantees 15TB of total write endurance. Eliminating >1TB of writes per week by moving the WAL off SSD is a pretty significant change, even though the burn rate isn't a simple linear thing--you won't burn the flash out in only 15 weeks. The production server is actually using the higher grade 710 drives that aim for 900TB instead. But I do have standby servers using the low grade stuff, so anything I can do to decrease SSD burn rate without dropping performance is useful. And only the top tier of transaction rates will outrun a RAID1 pair of 15K drives dedicated to WAL. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance