Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 5867F1337A5D for ; Wed, 6 Apr 2011 21:12:49 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 38480-05-3 for ; Thu, 7 Apr 2011 00:12:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from EXHUB018-2.exch018.msoutlookonline.net (exhub018-2.exch018.msoutlookonline.net [64.78.17.17]) by mail.postgresql.org (Postfix) with ESMTP id E00C31337C4C for ; Wed, 6 Apr 2011 21:10:33 -0300 (ADT) Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by EXHUB018-2.exch018.msoutlookonline.net ([64.78.17.17]) with mapi; Wed, 6 Apr 2011 17:10:33 -0700 From: Scott Carey To: Jeff CC: Merlin Moncure , Andy , "pgsql-performance@postgresql.org" , Greg Smith , Brian Ristuccia Date: Wed, 6 Apr 2011 17:10:31 -0700 Subject: Re: Intel SSDs that may not suck Thread-Topic: [PERFORM] Intel SSDs that may not suck Thread-Index: Acv0uDZ6YU8VV0ImRhu3GsRkhwwvXQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201104/58 X-Sequence-Number: 43120 On 3/29/11 7:32 AM, "Jeff" wrote: > >On Mar 29, 2011, at 10:16 AM, Jeff wrote: > >> Now that all sounds awful and horrible until you get to overall >> performance, especially with reads - you are looking at 20k random >> reads per second with a few disks. Adding in writes does kick it >> down a noch, but you're still looking at 10k+ iops. That is the >> current trade off. >> > >We've been doing a burn in for about 4 days now on an array of 8 >x25m's behind a p812 controller: here's a sample of what it is >currently doing (I have 10 threads randomly seeking, reading, and 10% >of the time writing (then fsync'ing) out, using my pgiosim tool which >I need to update on pgfoundry) Your RAID card is probably disabling the write cache on those. If not, it isn't power failure safe. When the write cache is disabled, the negative effects of random writes on longevity and performance are significantly amplified. For the G3 drives, you can force the write caches on and remain power failure safe. This will significantly decrease the effects of the below. You can also use a newer linux version with a file system that supports TRIM/DISCARD which will help as long as your raid controller passes that through. It might end up that for many workloads with these drives, it is faster to use software raid than hardware raid + raid controller. > >that was from a simple dd, not random writes. (since it is in >production, I can't really do the random write test as easily) > >theoretically, a nice rotation of disks would remove that problem. >annoying, but it is the price you need to pay > >-- >Jeff Trout >http://www.stuarthamm.net/ >http://www.dellsmartexitin.com/ > > > > >--=20 >Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-performance