Re: Testing FusionIO

From: david(at)lang(dot)hm
To: Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>
Cc: Justin Pitts <justinpitts(at)gmail(dot)com>, Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>, Ben Chobot <bench(at)silentmedia(dot)com>, PostgreSQL - Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Testing FusionIO
Date: 2010-03-17 20:14:19
Message-ID: alpine.DEB.2.00.1003171312330.10411@asgard.lang.hm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 installed capacity.
>>>> 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/formatting the drive for the intended usage, and not the max capacity, is the way to go. Capacity isn't an issue with this workload. I cannot fit enough drives into these servers to get a tenth of the IOPS that even Tom's documents the 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 reliable is 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Alvaro Herrera 2010-03-17 20:24:01 Re: Building multiple indexes concurrently
Previous Message Brad Nicholson 2010-03-17 20:01:56 Re: Testing FusionIO