Re: Testing FusionIO - Mailing list pgsql-performance

From david@lang.hm
Subject Re: Testing FusionIO
Date
Msg-id alpine.DEB.2.00.1003171312330.10411@asgard.lang.hm
Whole thread Raw
In response to Re: Testing FusionIO  (Brad Nicholson <bnichols@ca.afilias.info>)
List pgsql-performance
On Wed, 17 Mar 2010, Brad Nicholson wrote:

> On Wed, 2010-03-17 at 14:11 -0400, Justin Pitts wrote:
>> On Mar 17, 2010, at 10:41 AM, Brad Nicholson wrote:
>>
>>> On Wed, 2010-03-17 at 09:52 -0400, Justin Pitts wrote:
>>>> FusionIO is publicly claiming 24 years @ 5TB/day on the 80GB SLC device, which wear levels across 100GB of actual
installedcapacity. 
>>>> http://community.fusionio.com/forums/p/34/258.aspx#258
>>>>
>>>
>>> 20% of overall capacity free for levelling doesn't strike me as a lot.
>>
>> I don't have any idea how to judge what amount would be right.
>>
>>> Some of the Enterprise grade stuff we are looking into (like TMS RamSan)
>>> leaves 40% (with much larger overall capacity).
>>>
>>> Also, running that drive at 80GB is the "Maximum Capacity" mode, which
>>> decreases the write performance.
>>
>> Very fair. In my favor, my proposed use case is probably at half capacity or less. I am getting the impression that
partitioning/formattingthe drive for the intended usage, and not the max capacity, is the way to go. Capacity isn't an
issuewith this workload. I cannot fit enough drives into these servers to get a tenth of the IOPS that even Tom's
documentsthe ioDrive is capable of at reduced performance levels. 
>
>
> The actual media is only good for a very limited number of write cycles.  The way that the drives get around to be
reliableis to 
> constantly write to different areas.  The more you have free, the less you have to re-use, the longer the lifespan.
>
> This is done by the drives wear levelling algorithms, not by using
> partitioning utilities btw.

true, but if the drive is partitioned so that parts of it are never
written to by the OS, the drive knows that those parts don't contain data
and so can treat them as unallocated.

once the OS writes to a part of the drive, unless the OS issues a trim
command the drive can't know that the data there is worthless and can be
ignored, it has to try and preserve that data, which makes doing the wear
leveling harder and slower.

David Lang

pgsql-performance by date:

Previous
From: Brad Nicholson
Date:
Subject: Re: Testing FusionIO
Next
From: Alvaro Herrera
Date:
Subject: Re: Building multiple indexes concurrently