Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 2CB271337C12 for ; Wed, 6 Apr 2011 18:02:57 -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 90785-02-2 for ; Wed, 6 Apr 2011 21:02:47 +0000 (UTC) X-Greylist: delayed 00:10:04.728058 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 48E0F1337C51 for ; Wed, 6 Apr 2011 18:02:11 -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 13:52:05 -0700 From: Scott Carey To: Merlin Moncure , Andy CC: "pgsql-performance@postgresql.org" , Greg Smith Date: Wed, 6 Apr 2011 13:52:04 -0700 Subject: Re: Intel SSDs that may not suck Thread-Topic: [PERFORM] Intel SSDs that may not suck Thread-Index: Acv0nHzC4f7I4XuIQoS6gqBCdkWIFQ== 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/51 X-Sequence-Number: 43113 I have generation 1 and 2 Intel MLC drives in production (~150+). Some have been around for 2 years. None have died. None have hit the write cycle limit. We do ~ 75GB of writes a day. The data and writes on these are not transactional (if one dies, we have copies). But the reliability has been excellent. We had the performance degradation issues in the G1's that required a firmware update, and have had to do a secure-erase a on some to get write performance back to acceptable levels on a few. I could care less about the 'fast' sandforce drives. They fail at a high rate and the performance improvement is BECAUSE they are using a large, volatile write cache. If I need higher sequential transfer rate, I'll RAID some of these together. A RAID-10 of 6 of these will make a simple select count(1) query be CPU bound anyway. I have some G3 SSD's I'll be doing power-fail testing on soon for database use (currently, we only use the old ones for indexes in databases or unimportant clone db's). I have had more raid cards fail in the last 3 years (out of a couple dozen) than Intel SSD's fail (out of ~150). I do not trust the Intel 510 series yet -- its based on a non-Intel controller and has worse random-write performance anyway. On 3/28/11 9:13 PM, "Merlin Moncure" wrote: >On Mon, Mar 28, 2011 at 7:54 PM, Andy wrote: >> This might be a bit too little too late though. As you mentioned there >>really isn't any real performance improvement for the Intel SSD. >>Meanwhile, SandForce (the controller that OCZ Vertex is based on) is >>releasing its next generation controller at a reportedly huge >>performance increase. >> >> Is there any benchmark measuring the performance of these SSD's (the >>new Intel vs. the new SandForce) running database workloads? The >>benchmarks I've seen so far are for desktop applications. > >The random performance data is usually a rough benchmark. The >sequential numbers are mostly useless and always have been. The >performance of either the ocz or intel drive is so disgustingly fast >compared to a hard drives that the main stumbling block is life span >and write endurance now that they are starting to get capactiors. > >My own experience with MLC drives is that write cycle expectations are >more or less as advertised. They do go down (hard), and have to be >monitored. If you are writing a lot of data this can get pretty >expensive although the cost dynamics are getting better and better for >flash. I have no idea what would be precisely prudent, but maybe some >good monitoring tools and phased obsolescence at around 80% duty cycle >might not be a bad starting point. With hard drives, you can kinda >wait for em to pop and swap em in -- this is NOT a good idea for flash >raid volumes. > >merlin > >--=20 >Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-performance