Обсуждение: 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-application-specification-addendum.html
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-application-specification-addendum.html 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
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-application-specification-addendum.html
-- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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 !
On 8/24/2011 11:23 AM, Andy wrote:
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.
The underlying (Flash block) write rate really is terrible (and slower than most rotating disks).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 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.
On 08/24/2011 01:23 PM, Andy wrote:
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.
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
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.
---- 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, butI 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 mayhave to go back a year or so, since they've mostly stopped trying to graph HDD and SSD at the same time. Random is aworse 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 beshipped is up in the air. At one time mainframes had bespoke DASD. Not for more than a decade; they run on the same HDDyou 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
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
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
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