Webcast: Understanding the new culture of SharePoint
You have a sponsor for SharePoint development, you have a budget, now where are all the users? Online Collaboration powered by SharePoint is not only a new technology, but a new culture of doing work. In this session we’ll explore change management (the fluffy kind) strategies that can be tailored to your user base. Attract users, and keep your budget!
Presented by: Adam Levithan
> Register Now
> Live date: 7/28/2010 at 12:00 Pacific
SSD Again?
Yes…I had to come back to this topic. I find it important to share insight Scott sent in his early experiments with SSD. In my earlier editorials I was brainstorming about some of the things that may be possible with SSD.
I thought that it might be a great substitute for a ram disk containing TempDB? You can purchase SSD drives in the 2.5" laptop form factor for under $1k. So why not create a raid array of these drives and use it for TempDB?
Scott provides meaningful insight to the physics of an SSD. Solid State Drives are comprised of memory different than a RAM chip. It maintains the data without constant electrical supply…you don’t lose your contents when the lights go out. As a result, it works much like a highly improved thumb drive.
What this means, especially in the earlier SSD drives, is that bits go bad after a much smaller number of reads or writes than a physical disk. I won’t put any numbers here, because I don’t know what the technology can do today…but it is not the same as a hard disk. Interestingly, hard disks have the same problem. They are limited in the number of reads and writes a specific bit can handle. The number is many times more than that of the older technology SSD.
Does this mean that an SSD is not right for you? Not at all. What it means is that an SSD is not the solution for every situation. TempDB is constantly changing. Using an SSD for TempDB in the raid configuration I was talking about might last a while…but nowhere near as long as hard disks, or better yet…just put in more RAM.
Here’s Scott’s comments:
I was quite interested when I saw your mini-article on SSDs in today’s SSWUG. Your suggestion that SSDs might be useful as hosts for Swap files or TempDB reminded me of my own early experiences with this technology.
The important thing to remember is that SSDs experience poor reliability not because of some inherent flaw in the technology (as such), but rather because of their limitation in coping with very high write cycles. The more heavily written the drive is, the sooner it is likely to fail. There are all sorts of ways to limit this vulnerability (some of the algorithms used by drive manufacturers to ‘spread’ the writes, for instance, border on the supernatural), but ultimately it boils down to a very simple relationship, More Writes = Less Life.
Since TempDBs and Swapfiles are among the mostly write-heavy targets for any disk subsystem, it is thus likely that using SSDs to host them will simply lead to short, exciting lives for the drives in question. Your notion of putting the drives in well-designed arrays does of course limit the problems that you will encounter (and should also provide for even better performance), but it will catch up with you in the end, as you will have to swap out the dead (expensive) SSDs entirely too often. I have tried this myself (not for some time), and found the lifetime of the drives was well under 3 months. Obviously your mileage may vary (and with newer drives, it no doubt will), but overall I believe that the cost alone might make it a less than desirable approach.
I hope this has been enlightening to you as much as it has to me. Drop a line with your experiences or questions for discussing by our SSWUG group. Send your queries to btaylor@sswug.org.
Cheers,
Ben
Featured Article(s)
Surface Area Configuration Tool (Part 3 of 3)
In this part we will cover Native XML Web services in depth. We will analyze why analysis services are so important. Last we will go back to the SAC utility and finish out our demo.
Featured Script
ChangeAllObjOwner
This stored procedure can be used to run through all of a specific database’s objects owned by the ‘oldowner’ and change th… (read more)