SSD versus Enterprise SAS and SATA disks
by Johan De Gelas on March 20, 2009 2:00 AM EST- Posted in
- IT Computing
Disk strategies
With magnetic disks, there are two strategies to get good OLTP or mail server performance. The "traditional way" is to combine a number of 15000RPM SAS "spindles", all working in parallel. The more "rebellious way" or "Google way" is to use a vast number of cheaper SATA drives. This last strategy is based on the observation that although SATA drives come with higher access times, you can buy more SATA spindles than SAS spindles for the same price. While Google opted for desktop drives, we worked with what we had in the lab: 16 enterprise 1TB Western Digital drives. Since these are one of the fastest 7200RPM drives that can be found on the market, it should give you a good idea what an array with lots of SATA drives can do compared to one with fewer fast spinning SAS drives.
SSDs add a new strategy: if space is not your primary problem, you can trade in storage space for huge amounts of random I/O operations per second, requiring fewer but far more expensive drives to obtain the same performance. SSDs offer superb read access times but slightly less impressive write access times.
As Anand has pointed out, a cheap SSD controller can really wreak havoc on writing performance, especially in a server environment where many requests are issued in parallel. EMC solved this with their high-end Enterprise Flash Disks, produced by STEC, which can store up to 400GB and come with a controller with excellent SRAM caches and a super capacitor. The super capacitor enables the controller to empty the relatively large DRAM caches and write the date to the flash storage in the event of a sudden power failure.
Intel went for the midrange market, and gave its controller less cache (16MB). The controller is still intelligent and powerful enough to crush the competition with the cheap JMicron JMF602-controllers. We check out the SLC version, the Intel X25-E SLC 32GB.
The newest Intel Solid State Disks with their access times of 0.075 ms and 0.15W power consumption could change the storage market for OLTP databases. However, the SLC drives have a few disadvantages compared to the best SAS drives out there:
- No dual ports
- The price per GB is 13 times higher
You can see the summary in the table below.
| Enterprise Drive Pricing | ||||
| Drive | Interface | Capacity | Pricing | Price per GB |
| Intel X25-E SLC | SATA | 32GB | $415-$470 | $13 |
| Intel X25-E SLC | SATA | 64GB | $795-$900 | $12 |
| Seagate Cheetah 15000RPM | SAS | 300GB | $270-$300 | $0.90 |
| Western Digital 1000FYPS | SATA | 1000GB | $190-$200 | $0.19 |
If you really need capacity, SATA or even SAS drives are probably the best choice. On the other hand, if you need spindles to get more I/O per second, it will be interesting to see how a number of SAS or SATA drives compares to the SLC drives. The most striking advantages of the Intel X25-E SLC drive are extremely low random access times, almost no power consumption at idle, low power consumption at full load, and high reliability.
| Enterprise Drive Specifications | |||||
| Drive | Read Access Time | Write Access Time | Idle Power | Full Power | MTBF (hours) |
| Intel X25-E SLC 32GB | 0.075 ms | 0.085 ms | 0.06 W | 2.4 W | 2 million |
| Intel X25-E SLC 64GB | 0.075 ms | 0.085 ms | 0.06 W | 2.6 W | 2 million |
| Seagate Cheetah 15000RPM | 5.5 ms (*) | 6 ms | 14.3 W | 17 W | 1.4 million |
| Western Digital 1000FYPS | 13 ms (**) | n/a | 4 W | 7.4 W | 1.2 million |
(*) 5.5 ms = 3.5 ms seek time + 2 ms latency (rotation)
(**) 13 ms = 8.9 ms seek time + 4.1 ms latency (rotation)
Reliability testing is outside the scope of this document, but if only half of the Intel claims are true, the x25-E SLC drives will outlive the vast majority of magnetic disks. First is the 2 million MTBF specification, which is far better than the best SAS disks on the market (1.6 million hour MTBF). Intel also guarantees that if the X25-E performs 7000 8KB random access per second, consisting of 66% reads and 33% writes, the drive will continue to do so for 5 years! That is 2.9TB of written data per day, and it can sustain this for about 1800 days. That is simply breathtaking as no drive has to sustain that kind of IOPS 24 hours per day for such a long period.
Facebook
Twitter
RSS
67 Comments
View All Comments
JohanAnandtech - Friday, March 20, 2009 - link
If you happen to find out more, please mail me (johan@anandtech.com). I think this might have to do something with the inner working of SATA being sligthly less efficient than the SAS protocol and the Adaptec firmware, but we have to do a bit of research on this.Thanks for sharing.
supremelaw - Friday, March 20, 2009 - link
Found this searching for "SAS is bi-directional" --http://www.sbsarchive.com/search.php?search=parago...">http://www.sbsarchive.com/search.php?se...&src...
quoting:
> Remember, one of the main differences between (true) SAS and SATA is
> that in the interface, SAS is bi-directional, while SATA can only
> send Data in one direction at a time... More of a bottle-neck than
> often thought.
Thus, even though an x1 PCI-E lane has a theoretical
bandwidth of 250MB/sec IN EACH DIRECTION, the SATA
protocol may be preventing simultanous transmission
in both directions.
I hope this helps.
MRFS
supremelaw - Friday, March 20, 2009 - link
NOW!http://www.dailytech.com/article.aspx?newsid=14630">http://www.dailytech.com/article.aspx?newsid=14630
[begin quoteS]
Among the offerings are a 16GB RIMM module and an 8GB RDIMM module. The company introduced 50nm 2Gb DDR3 for PC applications last September. The 16GB modules operate at 1066Mbps and allow for a total memory density of 192GB in a dual socket server.
...
In late January 2009, Samsung announced an even higher density DRAM chip at 4Gb that needs 1.35 volts to operate and will be used in 16GB RDIMM modules as well as other applications for desktop and notebook computers in the future. The higher density 4Gb chips can run at 1.6Gbps with the same power requirements as the 2Gb version running at 1066Mbps.
[end quote]
supremelaw - Friday, March 20, 2009 - link
http://techreport.com/articles.x/16255">http://techreport.com/articles.x/16255The ACARD ANS-9010 can be populated with 8 x 2GB DDR2 DIMMS;
and, higher density SDRAM DIMMS should be forthcoming from
companies like Samsung in the coming months (not coming years).
4GB DDR2 DIMMs are currently available from G.SKILL, Kingston
et al. e.g.:
http://www.newegg.com/Product/Product.aspx?Item=N8...">http://www.newegg.com/Product/Product.a...tem=N82E...
I would like to see a head-to-head comparison of Intel's SSDs
with various permutations of ACARD's ANS-9010, particularly
now that DDR2 is so cheap.
Lifetime warranties anybody? No degradation in performance either,
after high-volume continuous WRITEs.
Random access anybody? You have heard of the Core i7's triple-
channel memory subsystems, yes? starting at 25,000 MB/second!!
Yes, I fully realize that SDRAM is volatile, and flash SSDs are not:
there are solutions for that problem, some of which are cheap
and practical e.g. dedicate an AT-style PSU and battery backup
unit to power otherwise volatile DDR2 DIMMs.
Heck, if the IT community cannot guarantee continuous
AC input power, where are we after all these years?
Another alternative is to bulk up on the server's memory
subsystem, e.g. use 16GB DIMMs from MetaRAM, and implement
a smart database cache using SuperCache from SuperSpeed LLC:
http://www.superspeed.com/servers/supercache.php">http://www.superspeed.com/servers/supercache.php
Samsung has recently announced larger density SDRAM chips,
not only for servers but also for workstations and desktops.
I predict that these higher density modules will also
show up in laptop SO-DIMMs, before too long. There are a
lot of laptop computers in the world presently!
After investigating the potential of ramdisks for myself
and the entire industry, I do feel it is time that their
potential be taken much more seriously and NOT confined
to the "bleeding edge" where us "wild enthusiasts"
tend to spend a lot of our time.
And, sadly, when I attempted to share some original ideas and
drawings with Anand himself, AT THE VERY SAME TIME
an attempt was made to defame me on the Internet --
by blaming me for some hacker who had penetrated
the homepage of our website. Because I don't know
JAVASCRIPT, it took me a few days to isolate that
problem, but it was fixed as soon as it was identified.
Now, Anand has returned those drawings, and we're
back where we started before we approached him
with our ideas.
I conclude that some anonymous person(s) did NOT
want Anand seeing what we had to share with him.
Your comments are most appreciated!
Paul A. Mitchell, B.A., M.S.
dba MRFS (Memory-Resident File Systems)
masterbm - Friday, March 20, 2009 - link
Still looks like their is bottleneck in raid controller in 66% read and 33% write test. The one ssd two ssd comperseionmcnabney - Friday, March 20, 2009 - link
The article does seem to skew at the end. The modeled database had to fit in a limited size for the SSD solution to really shine.So the database size that works well with SSD is one that requires more space than can fit into RAM and less than 500GB when the controllers top-out. That is a pretty tight margin and potentially can run into capacity issues as databases grow.
Also, in the closing cost chart there is no cost per GB per year line. The conclusion indicates that you can save a couple thousand with a 500GB eight SSD solution versus a twenty SAS solution, but how money eight SSD servers will you need to buy to equal the capacity and functionality of one SAS server.
I would have liked to see the performance/cost of a server that could hold the same size database in RAM.
JohanAnandtech - Friday, March 20, 2009 - link
"So the database size that works well with SSD is one that requires more space than can fit into RAM and less than 500GB when the controllers top-out. That is a pretty tight margin and potentially can run into capacity issues as databases grow. "That is good and pretty astute observation, but a few remarks. First of all, EMC and others use Xeons as storage processor. Nothing is going to stop the industry from using more powerful storage processors for the SLC drives than the popular IOP348.
Secondly, 100 GB SLC (and more) drives are only a few months away.
Thirdly, AFAIK keeping the database in RAM does not mean that a transactional database does not have to write to the storage system, if you want a fully ACID compliant database.
mikeblas - Friday, March 20, 2009 - link
I can't seem to find anything about the hardware where the tests were run. We're told the database is 23 gigs, but we don't know the working set size of the data that the benchmark touches. Is the server running this test already caching a lot in memory? How much?A system that can hold the data in memory is great--when the data is in memory. When the cache is cold, then it's not doing you any good and you still need to rely on IOPS to get you through.
JohanAnandtech - Friday, March 20, 2009 - link
http://it.anandtech.com/IT/showdoc.aspx?i=3532&...">http://it.anandtech.com/IT/showdoc.aspx?i=3532&...Did you miss the info about the bufferpool being 1 GB large? I can try to get you the exact hitrate, but I can tell you AFAIK the test goes over the complete database (23 GB thus), so the hitrate of the 1 GB database will be pretty low.
Also look at the scaling of the SAS drives: from 1 SAS to 8, we get 4 times better performance. That would not be possible if the database was running from RAM.
mikeblas - Friday, March 20, 2009 - link
I read it, but it doesn't tell the whole story. The scalability you see in the results would be attainable if a large cache were not being filled, or if the cache was being dumped within the test.The graphs show transactions per second, which tell us how well the database is performing. The charts don't show us how well the drives are performing; to understand that, we'd need to see IOPS, among some other information. I'd expect that the maximum IOPS in the test is not nearly the maximum IOPS of the drive array. Since the test wasn't run for any sustained time, the weaknesses of the drive are not being exposed.