SSD Lifetimes

  • Comments posted to this topic are about the item SSD Lifetimes

  • I have two desktop computers that have SSDs as their main drive, and backup to an external hard drive (USB 3). Backup times take about 15 minutes, which is another benefit of the drives. I've heard of new tech on the horizon that will replace these types of drives, but for the time being I'll be happy with my blazing fast performance.

  • for servers i would suggest mirrored pairs to help with safety.

    apparently there is a PCIe card that has a mirrored pair of SSD drives on it and runs faster than sata as its on the PCIe bus...

  • If you are going to protect your SSD with RAID then give it a good few months (or 10% of its expected life) to get some wear and then replace one of the SSDs with a new one. Due to RAID 1 having identical number of writes to both drives then the likelihood of both failing at very similar time becomes a moderate risk or at least you need to be incredible quick in replacing the failed drive. I know Iā€™m not the only DBA that has had more than one occasion where 2 scsi drives have failed within hours of one another.

  • Surely the very fact that you get a clearer picture of the impending expiry of the drives makes it less necessary to stage out the drive ageing? I'd be more inclined to recommend simply choosing two different drives or batches to avoid the more dangerous premature hardware failure. Assuming you aim for pro-grade drives rather than the lower end consumer devices that are driver-only, the drive is most likely to come with a toolset that gives fairly detailed information about the current drive health (Intel, for example). I'm pretty sure the fusionio software is also quite detailed, though I've no direct experience of their kit.

  • Landy_Ed (11/19/2012)


    Surely the very fact that you get a clearer picture of the impending expiry of the drives makes it less necessary to stage out the drive ageing? I'd be more inclined to recommend simply choosing two different drives or batches to avoid the more dangerous premature hardware failure. Assuming you aim for pro-grade drives rather than the lower end consumer devices that are driver-only, the drive is most likely to come with a toolset that gives fairly detailed information about the current drive health (Intel, for example). I'm pretty sure the fusionio software is also quite detailed, though I've no direct experience of their kit.

    You definitely want to use different batches of drives, whether mechanical or SSD. I've seen way too many failures at similar times in large batches of drives.

  • For drives that are meant to be Enterprise Class, the lifetime should be long enough for almost any application.

    The 400 GB drive on this link is rated a 35 PB of lifetime writes, so that would mean you could write 1 TB of data on it each day for 98 years, or 20 TB per day for 5 years.

    http://www.hgst.com/solid-state-drives/ultrastar-ssd400sb

    They are expensive though. I saw the price listed on one site at around $5,700.

  • Michael Valentine Jones (11/24/2012)


    The 400 GB drive on this link is rated a 35 PB of lifetime writes, so that would mean you could write 1 TB of data on it each day for 98 years, or 20 TB per day for 5 years.

    Gosh. That seems almost like nothing. Our main database only has 80GB but the legacy code has some pretty bad problems and easily writes several TB a day. Of course, we're working on fixing all of that but I'm sure that larger systems have similar problems and could easily reach 20TB per day especially on TempDB.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • FusionIO has listed 2 million hours and 6 years write endurance for their cards, ...

    Perhaps I'm reading something wrong but 6 years is only about 52,596 hours. 2 Million hours is more than 288 years so I doubt they've actually tested it for that.

    The 6 years number for write endurance is almost believable (I'd like to see the actual tests, though) but the 2 million hours sounds more like an expected non-operatioal shelf life than anything else. Is this nothing more than smoke'n'mirrors advertising with big unprovable numbers to impress and entice the unwary user?

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (11/25/2012)


    Michael Valentine Jones (11/24/2012)


    The 400 GB drive on this link is rated a 35 PB of lifetime writes, so that would mean you could write 1 TB of data on it each day for 98 years, or 20 TB per day for 5 years.

    Gosh. That seems almost like nothing. Our main database only has 80GB but the legacy code has some pretty bad problems and easily writes several TB a day. Of course, we're working on fixing all of that but I'm sure that larger systems have similar problems and could easily reach 20TB per day especially on TempDB.

    If the writes were spread over several drives in an array, that would still absorb a lot of writes. A 12 drive RAID5 array would give you 20 TB a day for 50 years. 5 TB per day would be still be a 20 year lifetime for a single drive. For the type of application that demands that level of performance, I think replacement of the server in 6 years or less would be closer to the norm.

    I think the price is still the biggest concern, and Enterprise SSD will still be too expensive for most applications. However, if your application is actually writing 20TB per day, then IO is likely a bottleneck, so it may be worth having a $55,000 10 drive SSD array.

    Hopefully, the price of SSD storage will continue to drop to the point of having costs closer to rotating mechanical disks.

  • Jeff Moden (11/25/2012)


    FusionIO has listed 2 million hours and 6 years write endurance for their cards, ...

    Perhaps I'm reading something wrong but 6 years is only about 52,596 hours. 2 Million hours is more than 288 years so I doubt they've actually tested it for that.

    The 6 years number for write endurance is almost believable (I'd like to see the actual tests, though) but the 2 million hours sounds more like an expected non-operatioal shelf life than anything else. Is this nothing more than smoke'n'mirrors advertising with big unprovable numbers to impress and entice the unwary user?

    I think they quote most mechanical disks with a MTBF of 1 million+ hours. I have to assume that they get these numbers from the reported failure rate of large numbers of disks, but maybe they just make them up.

  • Michael Valentine Jones (11/25/2012)


    Jeff Moden (11/25/2012)


    FusionIO has listed 2 million hours and 6 years write endurance for their cards, ...

    Perhaps I'm reading something wrong but 6 years is only about 52,596 hours. 2 Million hours is more than 288 years so I doubt they've actually tested it for that.

    The 6 years number for write endurance is almost believable (I'd like to see the actual tests, though) but the 2 million hours sounds more like an expected non-operatioal shelf life than anything else. Is this nothing more than smoke'n'mirrors advertising with big unprovable numbers to impress and entice the unwary user?

    I think they quote most mechanical disks with a MTBF of 1 million+ hours. I have to assume that they get these numbers from the reported failure rate of large numbers of disks, but maybe they just make them up.

    Yeah... I don't believe those numbers, either. šŸ˜›

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Michael Valentine Jones (11/25/2012)[hrHowever, if your application is actually writing 20TB per day, then IO is likely a bottleneck, so it may be worth having a $55,000 10 drive SSD array.

    Hmmm.... it [font="Arial Black"]really [/font]goes against my inner data-troll but, instead of spending who knows how much on fixing and regression testing the crap code that's causing all of those writes, it might just be worth the hardware investment.

    Part of the reason it goes against my inner data-troll is because I don't want to set the precedent that it's OK to write crap code just because the SSDs might be able to handle it especially since there's normally a fair amount of CPU time that goes along with the writes. CPUs cost a whole lot more than disks of any type if you consider licensing, etc, etc.

    An example of what I'm talking about (and I realize this has nothing to do with writes) is that one of our applications was setup to read a 4.7 million row table using a DISTINCT... to return a 51 row menu.... every time the menu was used... and it's used about 1,000 times per hour. It was using more than 4 CPU hours per 8 hour day and well over a TB of reads (just for this one menu!!!). The fix for that was pretty easy and we got the total CPU time down to seconds and the number of reads down to a sliver.

    My point is that with an SSD, people would be tempted to let something like that go but I suspect the CPU time used would still be there. It's also one of those pieces of code that was poorly written because the table was much smaller when this all started and the duration was satisfactory. Now, with SSDs, folks have an additional justification to pump out rather thoughtless code and because of the reduction in the duration caused by the increased I/O speed, an unwary DBA might not pick up on how much CPU time is being used for such a terribly simple thing.

    As with any growing system, we have a whole lot of other code in the same boat and it's just going to get worse for the CPUs.

    The writes are another thing caused simply by a lack of understanding of how to update data from one system to another. It involves mostly 2 large tables and I'm surprised it hasn't "cut a path" in the proverbial carpet of the current disk system. I think the related processes would be pretty tough on the life expectancy of the spots hit on an SSD for that. Even if I had SSDs that lasted a for a hundred years, the related unnecessarily high CPU usage is high enough to warrent fixing.

    Heh... of course, the way around the problem of keeping developers from writing additional CPU performance challenged code is to continue to do what I've always done. Use the worst server available for the Dev box. No SSDs there! šŸ˜›

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (11/26/2012)

    ...The writes are another thing caused simply by a lack of understanding of how to update data from one system to another. It involves mostly 2 large tables and I'm surprised it hasn't "cut a path" in the proverbial carpet of the current disk system. I think the related processes would be pretty tough on the life expectancy of the spots hit on an SSD for that...

    I believe that SSDs balance their writes so that data is actually written to a new spot each time in order to level the "write wear" over the entire memory area. Most have a significant over provisioning of memory cells in order to reach the stated lifetime.

    I agree that most performance issue have their origins in bad code, and the problems should be addressed there. However, there are times, especially with vendor supplied software, where you just can't do anything about it, and an SSD may provide relief.

    I had one a year ago where we had to use a large disk array to get the write performance we needed for an application that gathered network performance metrics for a large network. The database was actually fairly small, and I think it would have been more cost effective to use SSDs, but I just could not talk management into it.

  • Jeff Moden (11/26/2012)


    Michael Valentine Jones (11/25/2012)


    I think they quote most mechanical disks with a MTBF of 1 million+ hours. I have to assume that they get these numbers from the reported failure rate of large numbers of disks, but maybe they just make them up.

    Yeah... I don't believe those numbers, either. šŸ˜›

    They're statistical extrapolations. There's some science, but "mean" is "mean", not likely or expected. It means that half fail later, which implies that yours might fail tomorrow.

Viewing 15 posts - 1 through 15 (of 18 total)

You must be logged in to reply to this topic. Login to reply