Re: Testing FusionIO

From: Justin Pitts <justinpitts(at)gmail(dot)com>
To: Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>
Cc: 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 18:11:56
Message-ID: 1B61BA15-6D0A-489A-A85E-D4805E25F1B7@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


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.

>> Max drive performance would be about 41TB/day, which coincidently works out very close to the 3 year warranty they have on the devices.
>>
>
> To counter that:
>
> http://www.tomshardware.com/reviews/fusioinio-iodrive-flash,2140-2.html
>
> "Fusion-io’s wear leveling algorithm is based on a cycle of 5 TB
> write/erase volume per day, resulting in 24 years run time for the 80 GB
> model, 48 years for the 160 GB version and 16 years for the MLC-based
> 320 GB type. However, since 5 TB could be written or erased rather
> quickly given the performance level, we recommend not relying on these
> approximations too much."
>

I'm not sure if that is a counter or a supporting claim :)

>
>> FusionIO's claim _seems_ credible. I'd love to see some evidence to the contrary.
>
> Vendor claims always seem credible. The key is to separate the
> marketing hype from the actual details.

I'm hoping to get my hands on a sample in the next few weeks.

>
> Again, I'm just passing along what I heard - which was from a
> vendor-neutral, major storage consulting firm that decided to stop
> recommending these drives to clients. Make of that what you will.
>
> As an aside, some folks in our Systems Engineering department here did
> do some testing of FusionIO, and they found that the helper daemons were
> inefficient and placed a fair amount of load on the server. That might
> be something to watch of for for those that are testing them.
>

That is a wonderful little nugget of knowledge that I shall put on my test plan.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2010-03-17 18:44:56 Re: Building multiple indexes concurrently
Previous Message Bob Lunney 2010-03-17 17:02:03 Re: Block at a time ...