Costly SSDs Worth It, Users Say

Lucas123 writes "When you're paying $30,000 for a PCIe flash card, it had better demonstrate an ROI. While users are still struggling with why solid state storage cost so much, when they target the technology at the right applications, the results can be staggering. For example, when Dan Marbes, a systems engineer at Associated Bank, deployed just three SSDs for his B.I. applications, the flash storage outperformed 60 15,000rpm Fibre Channel disk drives in small-block reads. But when Marbes used the SSDs for large-block random reads and any writes, 'the 60 15K spindles crushed the SSDs,' he said,"

Meh

[Nom du Keyboard]

So sometimes it's faster, and sometimes it's slower, and always it's more expensive per GB. That makes this a pretty useless article.

Dan "Obvious" Marbes

[demonbug]

For example, when Dan Marbes, a systems engineer at Associated Bank, deployed just three SSDs for his B.I. applications, the flash storage outperformed 60 15,000rpm Fibre Channel disk drives in small-block reads. But when Marbes used the SSDs for large-block random reads and any writes, 'the 60 15K spindles crushed the SSDs,' he said,"

So when you need lots of small, random reads, 3x SSDs beat 60x HDDs. Most of the time is spent seeking the file on the HDDs, your ~4.6 ms random seek time is an order of magnitude or more slower than the flash-based drives. No surprise here.

When you are just transferring large files, most of the time is spent actually transferring data. A modern SSD might manage 300-400 MB/s read, but 20x as many HDDs are still going to beat the crap out of them.

The only mildly surprising part is that part about the HDDs winning for all writes, but I guess that really depends on how the test is set up - unless you are actually writing to random parts of the HDD, it is basically a straight-up write operation, so only throughput matters - and again, 60x HDDs are going to beat 3x SSDs (though it is important to note that SSDs are significantly slower at writing than reading in general, although still much faster than an HDD on an individual basis).

Re:So a good idea would be...

[wagnerrp]

Commercial SANs have had such tiered capability for years. Multiple levels of performance from bulk, long term storage on spinning disks to short term storage on SLC flash and finally a big memory cache. ZFS for Solaris and FreeBSD offers something similar with the L2ARC, allowing a cheaper but slower way to provide a large, high speed memory cache.

Seeks are an issue

[Anonymous Coward]

Just as an info dump for anyone who's not familiar with why SSDs perform so much better: SSDs have far better seek performance.

A normal HDD takes about 10ms to seek (3ms at the very high end, 15ms at the low end- 10ms is a good rule of thumb), which means you've got a princely 100 seeks per second per spindle (i.e. HDD). SSDs don't have seek limitations. Looking up a contiguous block of data vs not looking up a contiguous block of data makes no difference to an SSD.

It turns out that 100 seeks isn't a lot in serving infrastructure or, in some cases, on a desktop. When you go to read a file off disk multiple seeks are involved- you need to look up the inode (or equivalent), find the file and a large file will probably be in many different chunks require separate seeks to access them.

Even on a desktop you'll frequently be seek bound not throughput limited. Lets say you are starting up a largish java application (Eclipse might be a good example). It references a huge number of library (.jar) files which are certainly large enough to require many seeks to access. And those libraries are often linked in to system libraries which also have their own dependencies and may have additional dependencies all of which require further seeks. Plus with Eclipse it will look up the time stamps on files in the project... and so on.

During boot of a system is another time when HDD are usually seek bound- lots of different applications/services/daemons are starting at the same time, loading lots of libraries causing lots and lots of seeks.

On server infrastructure a highly utilized database will probably be seek bound not throughput limited.

The article is kind of stating the blindly obvious- if you are seek bound SSDs are better. And 60 drives gives ~6000 seeks. A typical modernish desktop HDD can get in the order of 100MB/s data transfer (average sustained), more expensive HDD can get quite a lot more. If we take 3.0Gb/s as a ceiling (i.e. the SATA 3.0 max transfer rate) then at 6000 seeks/second you are getting 3000MB/6000seeks=0.5MB per seek. So the result makes perfect sense if you looking up data that is either entirely non-contigous or smaller than 500kB- an SSD will beat you every time on seeks (since it has no seek time).

The limitations on SSDs are: they have throughput limitations, just like HDD and more importantly their write performance is usually significantly worse than a HDD (writing on an SSD often involves reading and re-writing large chunks of data, even for very small writes). You can easily construct tests where HDD perform better than SSDs (particularly something like a 60 spindle array of HDD where an awful lot of writes can be cached in the on disk's ram buffer, which is common on hire performance drives- often battery backed so they can "guarantee" the write has been committed without having to wait for a write to the magnetic media).

Of course SSDs other obvious application are where you want robustness and silence, i.e. laptops. Oddly enough their power performance isn't that much better than a normal HDD (although that might have changed since I last read about it).