pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
Intel 320 SSD info
11+ messages / 6 participants
[nested] [flat]

* Intel 320 SSD info
@ 2011-08-24 16:58 David Boreham <david_list@boreham.org>
  2011-08-24 17:17 ` Re: Intel 320 SSD info Merlin Moncure <mmoncure@gmail.com>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
  0 siblings, 2 replies; 11+ messages in thread

From: David Boreham @ 2011-08-24 16:58 UTC (permalink / raw)
  To: pgsql-performance


Apologies if this has already been posted here (I hadn't seen it before 
today, and
can't find a previous post).
This will be of interest to anyone looking at using SSDs for database 
storage :
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-enterprise-server-storage-applicat...





^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
@ 2011-08-24 17:17 ` Merlin Moncure <mmoncure@gmail.com>
  2011-08-24 17:23   ` Re: Intel 320 SSD info David Boreham <david_list@boreham.org>
  1 sibling, 1 reply; 11+ messages in thread

From: Merlin Moncure @ 2011-08-24 17:17 UTC (permalink / raw)
  To: David Boreham <david_list@boreham.org>; +Cc: pgsql-performance

On Wed, Aug 24, 2011 at 11:58 AM, David Boreham <david_list@boreham.org> wrote:
>
> Apologies if this has already been posted here (I hadn't seen it before
> today, and
> can't find a previous post).
> This will be of interest to anyone looking at using SSDs for database
> storage :
> http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-enterprise-server-storage-applicat...

hm, I think they need to reconcile those numbers with the ones on this
page: http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-320-series.html

600 write ips vs 3.7k/23k.

merlin



^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:17 ` Re: Intel 320 SSD info Merlin Moncure <mmoncure@gmail.com>
@ 2011-08-24 17:23   ` David Boreham <david_list@boreham.org>
  0 siblings, 0 replies; 11+ messages in thread

From: David Boreham @ 2011-08-24 17:23 UTC (permalink / raw)
  To: pgsql-performance

On 8/24/2011 11:17 AM, Merlin Moncure wrote:
>
> hm, I think they need to reconcile those numbers with the ones on this
> page: http://www.intel.com/content/www/us/en/solid-state-drives/solid-state-drives-320-series.html
>
> 600 write ips vs 3.7k/23k.
>
>

They do provide an explanation (and what I find interesting about this 
document is that they are basically "coming clean" about the real 
worst-case performance, which I personally find refreshing and 
encouraging). The difference is that the high number is achieved if the 
drive does not need to perform a block erase to process the write (this 
is true most of the time since the capacity is over-provisioned and 
there is an expectation that GC will have generated free blocks in the 
background). The low number is the performance under worst-case 
conditions where the drive is a) full and b) no blocks have been 
trimmed, and c) GC wasn't able to run yet.

I suspect that in production use it will be possible to predict in 
advance when the drive is approaching the point where it will run out of 
free blocks, and hence perform poorly. Whether or not this is possible 
is a big question for us in planning our transition to SSDs in production.

Anyone using SSDs should be aware of how they work and the possible 
worst case performance. This article helps with that !







^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
@ 2011-08-24 17:23 ` Andy <angelflow@yahoo.com>
  2011-08-24 17:25   ` Re: Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:41   ` Re: Intel 320 SSD info Greg Smith <greg@2ndQuadrant.com>
  2011-08-24 18:27   ` Re: Intel 320 SSD info Merlin Moncure <mmoncure@gmail.com>
  2011-08-24 20:50   ` Re: Intel 320 SSD info David Rees <drees76@gmail.com>
  1 sibling, 4 replies; 11+ messages in thread

From: Andy @ 2011-08-24 17:23 UTC (permalink / raw)
  To: David Boreham <david_list@boreham.org>; pgsql-performance

According to the specs for database storage:

"Random 4KB arites: Up to 600 IOPS"

Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not much faster than mechanical disks.

Has anyone done any performance benchmark of 320 used as a DB storage? Is it really that slow?


________________________________
From: David Boreham <david_list@boreham.org>
To: pgsql-performance@postgresql.org
Sent: Wednesday, August 24, 2011 12:58 PM
Subject: [PERFORM] Intel 320 SSD info


Apologies if this has already been posted here (I hadn't seen it before today, and
can't find a previous post).
This will be of interest to anyone looking at using SSDs for database storage :
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-320-enterprise-server-storage-applicat...



-- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
@ 2011-08-24 17:25   ` David Boreham <david_list@boreham.org>
  2011-08-24 17:46     ` Re: Intel 320 SSD info gnuoytr@rcn.com
  3 siblings, 1 reply; 11+ messages in thread

From: David Boreham @ 2011-08-24 17:25 UTC (permalink / raw)
  To: pgsql-performance

On 8/24/2011 11:23 AM, Andy wrote:
> According to the specs for database storage:
>
> "Random 4KB arites: Up to 600 IOPS"
>
> Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not 
> much faster than mechanical disks.
>
>
The underlying (Flash block) write rate really is terrible (and slower 
than most rotating disks).

The trick with SSD is that firmware performs all kinds of stunts to make 
the performance seen
by the OS much higher (most of the time !). This is akin to write-back 
caching in a raid controller,
for example, where much higher write rates than the physical drives 
support are achievable.

^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
  2011-08-24 17:25   ` Re: Intel 320 SSD info David Boreham <david_list@boreham.org>
@ 2011-08-24 17:46     ` gnuoytr@rcn.com
  0 siblings, 0 replies; 11+ messages in thread

From: gnuoytr@rcn.com @ 2011-08-24 17:46 UTC (permalink / raw)
  To: pgsql-performance



---- Original message ----
>Date: Wed, 24 Aug 2011 11:25:27 -0600
>From: pgsql-performance-owner@postgresql.org (on behalf of David Boreham <david_list@boreham.org>)
>Subject: Re: [PERFORM] Intel 320 SSD info  
>To: pgsql-performance@postgresql.org
>
>   On 8/24/2011 11:23 AM, Andy wrote:
>
>     According to the specs for database storage:
>     "Random 4KB arites: Up to 600 IOPS"
>     Is that for real? 600 IOPS is *atrociously
>     terrible* for an SSD. Not much faster than
>     mechanical disks.
>
>   The underlying (Flash block) write rate really is
>   terrible (and slower than most rotating disks).

At the lowest physical level, yes.  It's much simpler to flip the flux in the rust (I know, they've moved on from rust, but I can't give up the image) than to change state in NAND.  But that's hardly the point.

>
>   The trick with SSD is that firmware performs all
>   kinds of stunts to make the performance seen
>   by the OS much higher (most of the time !).

It's not an illusion.  Check the AnandTech (or Tom's or whoever you prefer) tests for sequential speeds vs. HDD.  You may have to go back a year or so, since they've mostly stopped trying to graph HDD and SSD at the same time.  Random is a worse comparison for HDD.  Yes, there are legitimate issues with power loss, especially in consumer and prosumer drives.  That's why STEC and Violin and Fusion-io and Texas Memory exist.  Whether bespoke controllers will continue to be shipped is up in the air.  At one time mainframes had bespoke DASD.  Not for more than a decade; they run on the same HDD you can buy at Newegg; better QA, but the same drive.


>   This is
>   akin to write-back caching in a raid controller,
>   for example, where much higher write rates than the
>   physical drives support are achievable.

Not really. Some SSD have lots o RAM cache, others have none at all (notably, SandForce controller).  See this: http://www.storagesearch.com/ram-in-flash-ssd.html



^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
@ 2011-08-24 17:41   ` Greg Smith <greg@2ndQuadrant.com>
  2011-08-24 17:42     ` Re: Intel 320 SSD info David Boreham <david_list@boreham.org>
  3 siblings, 1 reply; 11+ messages in thread

From: Greg Smith @ 2011-08-24 17:41 UTC (permalink / raw)
  To: pgsql-performance

On 08/24/2011 01:23 PM, Andy wrote:
> According to the specs for database storage:
>
> "Random 4KB arites: Up to 600 IOPS"
>
> Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not 
> much faster than mechanical disks.
>
> Has anyone done any performance benchmark of 320 used as a DB storage? 
> Is it really that slow?
>

Many SSDs that claim better are cheating though, or only quoting under 
conditions that don't take into account drive cleanup operations.  
That's fine in a non-database context, but if the data isn't any good to 
you unless it's guaranteed to be safe either on disk or on a 
non-volatile cache, Intel's numbers are the more relevant ones.  I 
wouldn't assume other drives really are better unless it's in a true 
apples to apples fair comparison.

I published some numbers at 
http://archives.postgresql.org/message-id/4D9D1FC3.4020207@2ndQuadrant.com 
that suggested 400 TPS was the worst-case for this drive on database 
random writes running the pgbench workload, which does a couple of 
writes per commit.  That's only 2X as fast as a typical mechanical hard 
drive running the same workload.  On random reads, the performance gap 
is much bigger, in favor of the SSD.

I've measured the performance of this drive from a couple of directions 
now, and it always comes out the same.  For PostgreSQL, reading or 
writing 8K blocks, I'm seeing completely random workloads hit a 
worst-case of 20MB/s; that's just over 2500 IOPS.  It's quite possible 
that number can go lower under pressure of things like internal drive 
garbage collection however, which I believe is going into the 600 IOPS 
figure.  I haven't tried to force that yet--drive is too useful to me to 
try and burn it out doing tests like that at the moment.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us

^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
  2011-08-24 17:41   ` Re: Intel 320 SSD info Greg Smith <greg@2ndQuadrant.com>
@ 2011-08-24 17:42     ` David Boreham <david_list@boreham.org>
  2011-08-24 20:11       ` Re: Intel 320 SSD info Greg Smith <greg@2ndQuadrant.com>
  0 siblings, 1 reply; 11+ messages in thread

From: David Boreham @ 2011-08-24 17:42 UTC (permalink / raw)
  To: pgsql-performance

On 8/24/2011 11:41 AM, Greg Smith wrote:
>
>
> I've measured the performance of this drive from a couple of 
> directions now, and it always comes out the same.  For PostgreSQL, 
> reading or writing 8K blocks, I'm seeing completely random workloads 
> hit a worst-case of 20MB/s; that's just over 2500 IOPS.  It's quite 
> possible that number can go lower under pressure of things like 
> internal drive garbage collection however, which I believe is going 
> into the 600 IOPS figure.  I haven't tried to force that yet--drive is 
> too useful to me to try and burn it out doing tests like that at the 
> moment.

I hope someone from Intel is reading -- it would be well worth their 
while to just send you a few drives,
since you are set up to perform the right test, and can provide 
impartial results.





^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
  2011-08-24 17:41   ` Re: Intel 320 SSD info Greg Smith <greg@2ndQuadrant.com>
  2011-08-24 17:42     ` Re: Intel 320 SSD info David Boreham <david_list@boreham.org>
@ 2011-08-24 20:11       ` Greg Smith <greg@2ndQuadrant.com>
  0 siblings, 0 replies; 11+ messages in thread

From: Greg Smith @ 2011-08-24 20:11 UTC (permalink / raw)
  To: pgsql-performance

On 08/24/2011 01:42 PM, David Boreham wrote:
> On 8/24/2011 11:41 AM, Greg Smith wrote:
>>
>>
>> I've measured the performance of this drive from a couple of 
>> directions now, and it always comes out the same.  For PostgreSQL, 
>> reading or writing 8K blocks, I'm seeing completely random workloads 
>> hit a worst-case of 20MB/s; that's just over 2500 IOPS.  It's quite 
>> possible that number can go lower under pressure of things like 
>> internal drive garbage collection however, which I believe is going 
>> into the 600 IOPS figure.  I haven't tried to force that yet--drive 
>> is too useful to me to try and burn it out doing tests like that at 
>> the moment.
>
> I hope someone from Intel is reading -- it would be well worth their 
> while to just send you a few drives,
> since you are set up to perform the right test, and can provide 
> impartial results.

Don't worry, they are.  With the big firmware bug in the 320 series 
lingering over things, it wasn't really worth wandering down that road 
yet until this week.  Now that they can ship me drives that are expected 
to work, I can pick back up work on performance testing them.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us




^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
@ 2011-08-24 18:27   ` Merlin Moncure <mmoncure@gmail.com>
  3 siblings, 0 replies; 11+ messages in thread

From: Merlin Moncure @ 2011-08-24 18:27 UTC (permalink / raw)
  To: Andy <angelflow@yahoo.com>; +Cc: David Boreham <david_list@boreham.org>; pgsql-performance

On Wed, Aug 24, 2011 at 12:23 PM, Andy <angelflow@yahoo.com> wrote:
> According to the specs for database storage:
> "Random 4KB arites: Up to 600 IOPS"
> Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not much
> faster than mechanical disks.
> Has anyone done any performance benchmark of 320 used as a DB storage? Is it
> really that slow?

I have one experience with 320 SSD that replaced a 4 drive RAID 10 10k
raid.  The site users and administrator in question gave summarized
the before/after experience thusly: "PFM" (Pure Magic).  Workload-wise
it was a largish database (200gb+), 50% read, 50% write, mixed
olap/oltp.

merlin



^ permalink  raw  reply  [nested|flat] 11+ messages in thread

* Re: Intel 320 SSD info
  2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
  2011-08-24 17:23 ` Re: Intel 320 SSD info Andy <angelflow@yahoo.com>
@ 2011-08-24 20:50   ` David Rees <drees76@gmail.com>
  3 siblings, 0 replies; 11+ messages in thread

From: David Rees @ 2011-08-24 20:50 UTC (permalink / raw)
  To: Andy <angelflow@yahoo.com>; +Cc: David Boreham <david_list@boreham.org>; pgsql-performance

On Wed, Aug 24, 2011 at 10:23 AM, Andy <angelflow@yahoo.com> wrote:
> According to the specs for database storage:
> "Random 4KB arites: Up to 600 IOPS"
> Is that for real? 600 IOPS is *atrociously terrible* for an SSD. Not much
> faster than mechanical disks.

Keep in mind that the 600 IOPS is over the entire disk.  performance
is much better over smaller spans - I suspect the 23,000 IOPS you
might see on the larger disks over an 8GB span are best case scenario,
though.

Moral of the story?  If you want the most performance, over-size your
SSD and "short-stroke" it.  Interesting to see that the 300/600GB
drives lose random write IOPS on the 100% span test over the smaller
disks - wonder if you limit access to the first 160GB if performance
matches the 160GB disk.  I kind of suspect that once you get to 20k+
random write IOPS over 8GB you've hit a controller limit on the SSD
since performance there reaches it's peak with the 300GB drive and the
160GB drive is less than 10% slower.

> Has anyone done any performance benchmark of 320 used as a DB storage? Is it
> really that slow?

Have the 120GB in my notebook.  Could run some tests if people are interested.

-Dave



^ permalink  raw  reply  [nested|flat] 11+ messages in thread


end of thread, other threads:[~2011-08-24 20:50 UTC | newest]

Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-08-24 16:58 Intel 320 SSD info David Boreham <david_list@boreham.org>
2011-08-24 17:17 ` Merlin Moncure <mmoncure@gmail.com>
2011-08-24 17:23   ` David Boreham <david_list@boreham.org>
2011-08-24 17:23 ` Andy <angelflow@yahoo.com>
2011-08-24 17:25   ` David Boreham <david_list@boreham.org>
2011-08-24 17:46     ` gnuoytr@rcn.com
2011-08-24 17:41   ` Greg Smith <greg@2ndQuadrant.com>
2011-08-24 17:42     ` David Boreham <david_list@boreham.org>
2011-08-24 20:11       ` Greg Smith <greg@2ndQuadrant.com>
2011-08-24 18:27   ` Merlin Moncure <mmoncure@gmail.com>
2011-08-24 20:50   ` David Rees <drees76@gmail.com>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox