Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 75CD6B5D803 for ; Thu, 16 Jun 2011 19:12:24 -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 20397-03 for ; Thu, 16 Jun 2011 22:12:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.postgresql.org (Postfix) with ESMTP id 631BDB5D801 for ; Thu, 16 Jun 2011 19:12:17 -0300 (ADT) Received: from [192.168.1.7] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lv6gg-1PXDiN0Nla-010QBa; Fri, 17 Jun 2011 00:12:09 +0200 Message-ID: <4DFA7FB8.80705@2ndQuadrant.com> Date: Thu, 16 Jun 2011 18:12:08 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: Merlin Moncure CC: pgsql-performance@postgresql.org Subject: Re: Performance advice for a new low(er)-power server References: <4DFA4EB7.1020701@2ndQuadrant.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:f6W+ZIwD+il/aXK7UDu8hn6TpjSNz5VBnVCEfexX2wo kLD5DMXzpzkk6eCw2DyiCAW2yPSwYv9Vfaz//dORq+lIX+RB4u /ZeWo5Ggfr3GILG2qDdoEAJAy9PLjjI3ol1HuC3D8+QMgh8rUg brWIBGMvJN/7LUNucIY/NJesWgTa4gDpgdYHMkw72UFn+BEJEU YGfoktg3HhHueCRdIFR3PuK9SzPbnYYGXyl9iujDd8= 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, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201106/148 X-Sequence-Number: 44081 On 06/16/2011 03:04 PM, Merlin Moncure wrote: > I don't necessarily agree. the drives are SLC and have the potential > to have a much longer lifespan than any MLC drive, although this is > going to depend a lot on the raid controller if write caching is > disabled. Also, reading the post that got all this started > (http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-fsync-write-cache-barrier-and-lost-transactions/), > the OP was able to configure them to run durably with 1200 write iops. > We've also seen http://petereisentraut.blogspot.com/2009/07/solid-state-drive-benchmarks-and-write.html where Peter was only able to get 441 seeks/second on the bonnie++ mixed read/write test that way. And no one has measured the longevity of the drive when it's running in this mode. A large portion of the lifespan advantage MLC would normally have over SLC goes away if it can't cache writes anymore. Worst-case, if the drive is always hit with 8K writes and the erase size is 128KB, you might get only 1/16 of the specified lifetime running it cacheless. I just can't recommend that people consider running one of these in a mode it was never intended to. The fact that the consumer drives from this generation still lose data even with the write cache turned off should make you ask what other, more difficult to trigger failure modes are still hanging around the enterprise drives, too. Everyone I've seen suffer through problems with these gave up on them before even trying really in-depth reliability tests, so I don't consider that territory even very well explored. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books