DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=k0bJrJPIdST1SqMx+lloGDpj3XHal6xKYIfFb2I6dNi+nnzMlDrKRTAqn0GmFKmTBG
	R8euEBb5ErPUwtEM2ohVAh7D/oSkJIvCG9eGAqkI9q0ddC9e4iheBzYTjNWyn/GG6rgJ
	4qaii+kYBzf8+RTGBrMFkKfNiSViXaQqKgKy8=
MIME-Version: 1.0
In-Reply-To: <4DFA7FB8.80705@2ndQuadrant.com>
References: <BANLkTinXa4ZVigTQ7Q=05saam_3GZdyx7g@mail.gmail.com>
	<4DFA4EB7.1020701@2ndQuadrant.com>
	<BANLkTin1BZN6oAy-OJT4URJMDsMtHQ3ahA@mail.gmail.com>
	<4DFA7FB8.80705@2ndQuadrant.com>
Date: Thu, 16 Jun 2011 17:44:11 -0500
Message-ID: <BANLkTi=eu9v5dVmeUgTsmMZvwiO2jNxjzA@mail.gmail.com>
Subject: Re: Performance advice for a new low(er)-power server
From: Merlin Moncure <mmoncure@gmail.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 16, 2011 at 5:12 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> 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. =A0Also, 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. =A0And no one has measured the longevity of the
> drive when it's running in this mode. =A0A large portion of the lifespan
> advantage MLC would normally have over SLC goes away if it can't cache
> writes anymore. =A0Worst-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 lifetim=
e
> running it cacheless.
>
> I just can't recommend that people consider running one of these in a mod=
e
> it was never intended to. =A0The fact that the consumer drives from this
> generation still lose data even with the write cache turned off should ma=
ke
> you ask what other, more difficult to trigger failure modes are still
> hanging around the enterprise drives, too. =A0Everyone 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.

I've always been more than little suspicious about Peter's results --
using lvm and luks, and the filesystem wasn't specified or the write
barriers setting.  Also they are much slower than any other results
I've seen, and no numbers are given using a more standard setup.
Other people are showing 1200 write iops vs 441 mostly read iops.  Not
that I think they aren't correct, but there simply has to be an
explanation of why his results are so much slower than all others on
the 'net...I think 1200 write iops is a realistic expectation.

One the cache/lifespan issue, you might be correct -- it's going to
depend on the raid controller. The drive has a 10x longer lifespan and
there is not going to be a 1:1 correspondence between sync requests
and actual syncs to the drive.  But the drive is denied the ability to
do it's own reordering so unless the raid controller is really
optimized for flash longevity (doubtful), you probably do have to give
back a lot of the savings you get from being SLC (possibly more).  So
it's complex -- but I think the whole issue becomes moot soon because
non consumer flash drives from here on out are going to have
capacitors in them (the 720 ramsdale will immediately knock out the
x25-e). So the prudent course of action is to wait, or to just go with
the current crop capacitor based drives and deal with the lifespan
issues.

merlin