Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Data Storage Hardware

Costly SSDs Worth It, Users Say 288

Posted by Soulskill from the dollars-per-patience dept.
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,"
This discussion has been archived. No new comments can be posted.

Costly SSDs Worth It, Users Say More

Costly SSDs Worth It, Users Say

Comments Filter:

  • My approach (Score:5, Informative)

    by Anrego ( 830717 ) * on Tuesday September 06, 2011 @06:38PM (#37321794)

    Small (and cheap) 32GB SSD for my desktop...

    Big powerful 12TB file server using traditional disks for the bulk of my data.

    Performance for the stuff where the SSD makes a difference (program files), cheap storage for the stuff where it doesn't (just about everything else).

    And if that 32GB drive dies (unproven technology.. MTBF is still a guess) .. I'll buy another cheap (probably cheaper at that point) one and restore from my daily backup.

    • I do the same thing as you do except I keep a hot spare in my computer, a regular hard drive that automatically mirrors the SSD using Norton Ghost. If the SSD dies, swap the SATA cables and reboot. I've done this a few times just to test it out, and it works.

      • Re: (Score:2)

        by Sabriel ( 134364 )

        Is that "except" or "except also"? If the primary dies whilst being mirrored... may I suggest two spares with an alternating schedule? :)

        • Just use rsync with "--link-dest", I've seen multi-TB backups take less than a minute because most of the files are the same.

          • It depends on the application, and how it stores its data. Not all scenarios are conducive to rsync; it is possible for an rsync to take more time than just doing a copy.

            • Those situations are pretty rare, usually as a result of databases that store many GB in a single file. And if you're backing up a database it's usually best to use whatever online backup mechanism the database provides anyway, so that you don't have to take it offline every day for backups.

    • I did the same thing for a small media server I set up; bought a Via picoitx system and on a whim chose a 60G SSD to install the os on, and use a 2 TB usb drive to serve up the media. Works really well. The ssd is good on heat.

    • You have a 12TB file server? WTF are you putting on that thing, pirated content you'll never have enough time in your life to watch?

      • Re: (Score:2)

        by Anrego ( 830717 ) *

        Rips of my fairly massive DVD collection actually!

        Ok, I won't lie, I do have some pirated content.. but I do pay for most of my media these days.

        It adds up fairly quickly... most are in H.264 with fairly high settings.

        And yes, I have seen everything in my collection. I almost always have something playing in the background while I work. I probably make it through my collection every few years ..

      • 12TB is a lot, unless you start backing up your entire blu ray collection to disk, in which case it might not be that much. Also if you're into shooting HD video.

      • Re: (Score:2)

        by drsmithy ( 35869 )

        You have a 12TB file server? WTF are you putting on that thing, pirated content you'll never have enough time in your life to watch?

        12T isn't a lot once you start putting 8-12GB per movie and ~25GB per season 1080p rips. Especially if you keep them for rewatching.

        • 25GB per season is 480 seasons of TV per 12 TB. Rewatching? You'd be lucky to watch all of those. Assuming you watch 3 hours of TV a day, and (this is very conservative) there are 12 episodes per season, that's 5 years of watching TV before you repeat a single episode.

          • Re: (Score:2)

            by dgatwood ( 11270 )

            I think the original figure must have been missing a zero. 25 GB per season is less than 480i DVD bitrate (that's only about three dual-layer DVDs, whereas an hour-long TV series has about five or six dual-layer discs per season.

            I only have one TV show on Blu-Ray, so I don't have a lot of data to go on, but... Serenity ran for only 14 episodes (basically a half season) and is spread across three dual-layer Blu-Ray discs, for a total of 150 GB. A full season of an hour-long TV show should be on the order o

            • So it's only 48 seasons then?

              Star Trek TOS: 3 seasons
              Star Trek TNG: 7 seasons
              Star Trek DS9: 7 seasons
              Star Trek VOY: 7 seasons
              Star Trek ENT: 4 seasons
              Babylon 5: 5 seasons

              That's 33 seasons right there. And what self respecting geek wouldn't have those?

            • Re: (Score:2)

              by drsmithy ( 35869 )

              I only have one TV show on Blu-Ray, so I don't have a lot of data to go on, but... Serenity ran for only 14 episodes (basically a half season) and is spread across three dual-layer Blu-Ray discs, for a total of 150 GB. A full season of an hour-long TV show should be on the order of 250-300 GB unless you are recompressing it at a much lower quality setting.

              25GB is a pretty standard size for a HDTV-ripped, x264-encoded, ~22-24 episode season on tvtorrents, et al.

              Rips from full BR sources seem to come in more

          • Nah, he's just storing multiple backups of FRIENDS, everybody knows you only need FRIENDS and just go back to the start when you run off the end, it's the mobius strip of Television.

    • Re: (Score:2)

      by cgenman ( 325138 )

      I have a 128GB SSD for OS and scratch partition, with data and programs on a larger traditional HDD. Going to SSD, the boot speed more than doubled. Applications that rely on scratch disks, like Photoshop... Well, Photoshop is a bit confused by the whole setup. But SMARTER applications that rely upon scratch disks are lightning fast. It's not just that the SSD functions as a scratch disk faster, but that by offloading those IO interactions means that the normal disk is entirely free for more traditional

    • I run RF simulations at work and loaded up the RAM to cache terrain data.

      64GB system memory was $1500 a few months ago. I think it is below $1000 now.

      Skip the SSD and load up on ram.

      Once it's cached, leave it there.

      I'd like to see a thunderbolt RAM drive .. that'd be something; in my youth I'd have given it a go. Put some backup batteries in there, a mirror HD, and voila - block reads to go, in bulk. Sweet little capacitors. Do my bidding!

      • Re: (Score:2)

        by afidel ( 530433 )
        That works if your data set is smaller than 64GB, our BI dataset is 320GB and expected to double in size in the next year or two. I put it on a $15,000 card from FusionIO (MLC 640GB) and have achieved great performance, there's no way I could have achieved anywhere near the same performance with an extra $15k in the server or the SAN.

  • Meh (Score:2, Interesting)

    by Nom du Keyboard ( 633989 )
    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.

    • Re:Meh (Score:5, Informative)

      by Rockoon ( 1252108 ) on Tuesday September 06, 2011 @07:40PM (#37322188)
      15K enterprise drives cost around ~$1/gigabyte ... not all that much cheaper than SSD's which cost around ~$2/gigabyte (MLC) or ~$5/gigabyte (SLC)

      Now, the comparison in the summary is between 3 SSD's and 60 15K HDD's.. in other words, the HDD solution was enormously more expensive. (and thats NOT counting the cost of the stack of Fiber Channel raid enclosures, let alone the power that 60 stack draws)

      You dont seem to know what you are talking about. SSD's arent much more expensive per gigabyte than HDD's in performance enterprise environments, and always significantly outperform for equal investment, with less power costs. The only place the "cheaper per gigabyte" argument is true is when you can get away with inexpensive HDD's.. in other words, you heard people talk about one thing but didnt know that it didnt apply to another.

      When you dont know what you are talking about, act like it.

      • Re:Meh (Score:4, Informative)

        by antifoidulus ( 807088 ) on Tuesday September 06, 2011 @08:02PM (#37322302) Homepage Journal
        The difference is even starker when you take rack space into account. The largest 15k drive I could find was 600 gb. Enterprise SSDs on the other hand(if you dont want to go the PCIE route) are right now approaching 1 TB for a 3.5" drive, and the difference in density between the two is only going to grow. The reduced amount of rack space SSDs take up is going to further decrease operating costs.

        • Whats the price difference between 2 600GB mechanicals and the 1 1TB drive?

          Also, whats MTBF, and is that SSD using internal RAID0 like I think it is? If so, have fun with data recovery when one flash failure kills the entire 1TB.

          • Wow, that wasnt even REMOTELY related to what we were talking about, good job! How many enterprises run their 15k RPM hard disks inside enclosures in RAID 0? Hint, the number is probably not much more than the RAID level. The grandparents point was that while the drive costs are different, the fact of the matter is that powering those 15k drives(and of course removing the heat they create) starts to get pretty expensive after a while meaning that overall although the drives are cheaper when you buy them

            • Re: (Score:2)

              by Sancho ( 17056 ) *

              Not the GP, but I suspect he was referring to the fact that the OCZ Colossus 1TB SSD is internally a RAID 0. If an enterprise is running these, they're running RAID0, but may not even realize it.

              http://www.ocztechnology.com/ocz-colossus-lt-series-sata-ii-3-5-ssd.html [ocztechnology.com]

              That said, it starts at $2500. The 600GB 15k SAS drives start at $650. $1200 (comparing 2 SAS to 1 SSD) buys you a lot of rack space and cooling. If you look at "Enterprise SSD" (whatever that means), you're looking at requiring a PCI-E card

          • Whats the price difference between 2 600GB mechanicals and the 1 1TB drive?

            The limiting factor may be space. If the 1x1TB drive fits into a 1U enclosure but the 2x600GB drive requires a 2U enclosure, it may not be worth doubling your datacenter rack space for the storage.

            The limiting factor may be reliability. Mechanical drives fail frequently on startup/shutdown due to temperature changes. Putting two mechanical drives in a host (instead of one solid-state) sounds like a good way to increase failure

      • At $30,000 per SSD, times 3, you get $90,000. Divide that by 60 and you get $1,500 per hard drive to break even.

        Im not sure Ive ever seen a hard drive that costs $1,500; Newegg says [newegg.com] 450GB SAS 15k drives can be had for $300.

        But then, we dont know how much data is being stored by that SSD, or how much was being stored by the mechanicals, or how much parity (if any?) each system had, or whether they were from the same vendor... all of which make the article pretty darn useless.

        They mention, for example, that

        • Re: (Score:2)

          by afidel ( 530433 )
          I'm paying about $1,000 for 450GB 15k's with 5 years of 4 hour coverage, but that doesn't include the shelf, installation, the controllers, the SAN switches, the HBA's, or the RAID overhead. For me the equation was simple, for our ERP system the DB went onto mirrored SLC flash cards where we get lower latency than 15k disks could hope to give us even with a decent amount of cache in front because the workload is random. For what I spent on those two SSD's I couldn't have bought even 3 shelves of additional

  • Dan "Obvious" Marbes (Score:5, Interesting)

    by demonbug ( 309515 ) on Tuesday September 06, 2011 @06:48PM (#37321870) Journal

    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).

    • the writes probably win because the raid controller stripes the writes across all 60 drives instead of just the 3. If you had 60 SSDs versus 60 platters, I would be willing to bet that the SSDs win every time.

    • The only mildly surprising part is that part about the HDDs winning for all writes,

      Maybe their SSD doesnt support TRIM. That would certainly explain it.

  • While this summary should never have been posted here (please taco, give us good stuf, not 'I know how to move the mouse pointer so I am a l33t hax0r-stuf) but the full article is interesting. It gives a couple of hands-on experiences from users that are quite interesting. It seems the SSD can gain you speed in more situations than previously thought/marketed. Although for my uses I'm not going to spend more than 2 dollar/euro per GB.

  • i've had a bad experience with SSD drives having returned 2 due to deal breaking problems for me .... on caused BSODs the other could handle suspend mode without locking up.

    I have now 2x samsung F3s in raid 0 (plus back up on NAS)

    personally i have no desire to have to do the sort of file management small sized SSDs currently demand and since reading the reviews they all pretty much suck.... however SRT is a compelling option... all the convenience of big mechanical drives plus a speed boost of SSD ... unl

    • This is partly your fault for trusting a company called OCZ with a brand new controller (SandForce) that was only apparently optimized for speed. Be a little conservative and it'll pay off. I'm a happy owner of a WD Sliconedge Blue branded drive in a gaming box and I've been very happy with it. It's no speed demon but it works well. Not sure what SSD came with my imac but needless to say that works fine as well.
      • I had issues with a couple of Intel's SSDs myself, which were the top rated for the time, still using a 160GB Intel SSD in my MBP, and a 115GB Corsair SSD in my desktop now. The Corsair is a year and a half newer, but works really well. I have other storage on my desktop + NAS... so only the laptop gets cramped from project/VM data on occasion.

  • SSDs for lower power, low noise environments (Score:3)

    by oracleguy01 ( 1381327 ) on Tuesday September 06, 2011 @07:04PM (#37321980)

    To me the cost per GB of an SSD really makes it tough to justify in a lot of cases especially if you want to store large programs like games where you'll need at least a 100GB SSD. However one area place I have started to use low capacity (8 or 16GB) SSDs are in low noise and/or low power environments. If you team them with an ITX Atom board and the right power supply you can build a small computer with no moving parts whatsoever. And the computer will have a very low power usage for applications like HTPCs or network appliances (like firewalls) where the machine might always be powered on.

  • The outcome is not exactly what they said (Score:3)

    by Courageous ( 228506 ) on Tuesday September 06, 2011 @07:27PM (#37322116)

    If you think about it, the outcome of this test is 100% in favor of the SSD.

    Think about it:

    The tester was willing to test only 3 SSD's versus *60* 15K drives. So the tester thought that 20 times fewer drives was a fair test for the comparison. What is the tester actually saying here? I think I have a feeling I know. :-)

    Anyway, 15K drives are not long for the market. Soon, all that will be left are economy class, 10K, and SSD's.

    Only a little more maturity, and the enterprise flood gates will open. When that happens, the hapless victim will be the short stroked IOPS environment, where total IOPS was always the requirement, and that requirement was for more IOPS than capacity. I.e., if a 15K drive offers 400 IOPS, and you need 400,000 sustained, but don't have to store very much at all, your only current choices are buying a lot of 15K drives. Or a bazillion less SSD's.

    The switchover point is only a heartbeat away.

    Bye 15K drive. I'll miss you.

    C//

    • The tester was willing to test only 3 SSD's versus *60* 15K drives.

      Except they COMPLETELY neglected to mention whether there was parity in place on either system, or how much data was being held by each system.

      Protip-- the mechanicals were holding a TON more data than the SSD systems, and im pretty sure the mechanicals can be hotswapped.

  • Get one. It's worth it.

  • Seeks are an issue (Score:3, Interesting)

    by Anonymous Coward on Tuesday September 06, 2011 @07:29PM (#37322128)

    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).

     

    • 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).

      That depends on the manufacturer. My intel SSD requires less than 750mA at full tilt. I have an OCZ SSD that uses 2A all the time.

    • That 100 seeks per second isnt the entire story, however-- basically every drive you can possibly get these days supports Native Command Queuing, which means that the drive will try to organize its reads so that it doesnt have to seek to position 50 to grab a block of data, then reseek to position 40 to grab another block. With NCQ, it would rearrange the requests so that it first gets position 40, then goes to 50 within the same "rotation"-- so both requests were done in under that 10ms.

      NCQ makes a huge d

      • Re: (Score:2)

        by afidel ( 530433 )
        Doesn't matter, even if you take the best 15k 2.5" (short stroked to 1.8" internally) drive you can buy from HP (and I haven't seen better specs from anyone else) you still get an average latency of ~2.6ms versus a worst case latency of 1.1ms for my SLC cards (average .08ms).

    • Looking up a contiguous block of data vs not looking up a contiguous block of data makes no difference to an SSD.

      Then is it safe to say that we should never again worry about running defrag utilities after moving to SSD?

      • Yes, this is one major reason for performance improvements on desktop systems. Fragmentation is not an issue (well, sorta) with SSDs.

        (I say sorta, because due to the way NAND erases are handled a highly fragmented filesystem can cause write amplification and slowdowns as blocks are reclaimed. TRIM helps with this.)

  • . . . a Storage Review experiment from over a year ago:

    http://www.storagereview.com/western_digital_velociraptors_raid_ssd_alternative [storagereview.com]

    They put WD Raptors in RAID 0 to form a high performance (yet still affordable) platter drive setup, and then faced them off against Western Digital's new (at the time, first) SSD. Makes sense, right? Except that WD's first SSD was a complete joke, an underperforming [anandtech.com], laughably expensive POS that I forgot about a couple days after Anand's review. When I first read about i

  • There is no such thing as poor performance on an SSD, unless you allocate it poorly. The fact that most companies aren't paying attention to fantastic ways to get reasonably priced SSDs into their equipment just proves that hype is awesome and smart still sucks. Luckily for me, smart is still making money (though not nearly as much as hype).

    • Sure there is, if your drive doesnt support TRIM (or hasnt TRIM'd in a while)-- that can certainly result in a slower drive.

  • My own very recent experience (2 weeks ago) (Score:4, Informative)

    by Raleel ( 30913 ) on Tuesday September 06, 2011 @09:25PM (#37322690)

    I moved a small 4TB database from 24x 256G 15k SAS drives to 24x 240G OCZ Vertex 3 SATA3 drives. I ran a few queries on the old and the new. same data, same parameters, same amount of data pulled. Both were hooked up via PCIe 8x slots.

    the SSD crushed the SAS. Not just a mere 2x or 3x crushing. A _FIFTEEN TIMES FASTER_ crushing. This was pulling about a million rows out. 12 seconds (SSD) vs 189 seconds (spindles)

    Cost difference? under $50 per drive more expensive for SSD. I think our actual rate was around $10 per drive more. However, the system as a whole (array+drives+computer) was $12k less. No contest... for our particular application, SSD hands down makes it actually work.

    we'll be moving the larger database (same data, same function) to SSD as soon as we can.

  • ...when your selection criteria is cost-per-IOPS. For heavy, random IOs (like transactional databases) SSD presents a cheaper solution.

    Anyway, that's my two-sentence rewrite of TFA.
  • People go to great lengths to minimize read/writes; putting their games and apps on a HDD, changing system/user folder locations to a HDD, etc. So basically is it worth it to merely load the operating system a little bit faster? Why buy an SSD if you aren't going to use it to load your games and apps faster?

  • I would like to see the performance gain in eve. This could reduce lag significantly.

  • Why is the NetApp Flash Cache so pricey? (Score:3)

    by this great guy ( 922511 ) on Wednesday September 07, 2011 @12:43AM (#37323732)

    On "why does NetApp sell their PCIe NAND flash card $30k?", here is your answer, Chris Rima: http://blog.zorinaq.com/?e=37 [zorinaq.com]

    In a 3 words: because NetApp can.

    It's not the components or engineering behind the card that cost $30k. NetApp prices it so high because the card boosts the performance of their filers by about the same amount as a ~$50k shelf of SAS disks (click that link and go read NetApp's own marketing documentation). They have got to have price points that make sense to customers.

    (I know a fraction of you will think "No way!". Well, arbitrary price markups on enterprise gear do exist. This NetApp Flash Cache is effectively priced $150/GB. How do you think that certain competitors can even sell _enterprise_ flash at well below $10/GB? We are not talking 25 or 50% less, but a whole order of magnitude less expensive!)

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close