A Look at Enterprise Performance of Intel SSDs(anandtech.com)
anandtech.com
A Look at Enterprise Performance of Intel SSDs
http://www.anandtech.com/show/5518/a-look-at-enterprise-performance-of-intel-ssds
4 comments
> Over the years our servers seem to die in the following order: hard drives, power supplies, motherboards. We tend to stay on a hardware platform until the [...] motherboards start dying
Hum, that's quite surprising. I currently tend about 250 servers, and server motherboards live way past any useful life.
In the 5 past years, I've replaced about one hundred disk drives, a few power supplies, two RAID controllers and zero failed motherboard.
This week I replaced a 2004-era motherboard by a newer 2008 one, because of its lack of SATA ports; the old board still works fine, but is becoming hard to work with (no SATA, no PCIe, DDR-1 RAM, 32 bits only...).
Hum, that's quite surprising. I currently tend about 250 servers, and server motherboards live way past any useful life.
In the 5 past years, I've replaced about one hundred disk drives, a few power supplies, two RAID controllers and zero failed motherboard.
This week I replaced a 2004-era motherboard by a newer 2008 one, because of its lack of SATA ports; the old board still works fine, but is becoming hard to work with (no SATA, no PCIe, DDR-1 RAM, 32 bits only...).
It depends on how you service your boxes, and how much whiz-bang crap is on the motherboard.
If you rely on vendors to service the boxes, and use a vendor like IBM that likes to tweak the firmware of the boards, you're going to have alot of random crap diagnosed as "motherboard failure".
Many of these issues are really configuration or software issues -- issues that the SAs should be fixing by keeping firmware up to date. Back in the 90's, the vendor CE's would have a clue and advise the customer staff to try applying software fixes, or stop using buggy feature X. But these days, the smart CEs are mostly dead, retired, or laid-off, and their replacements are often contracted out people who just know how to swap out parts. (Or have an incentive for you to have more failures, since part swaps == money.)
If you as an admin actually service your stuff, you'll notice failure patterns and actually troubleshoot the stuff.
If you rely on vendors to service the boxes, and use a vendor like IBM that likes to tweak the firmware of the boards, you're going to have alot of random crap diagnosed as "motherboard failure".
Many of these issues are really configuration or software issues -- issues that the SAs should be fixing by keeping firmware up to date. Back in the 90's, the vendor CE's would have a clue and advise the customer staff to try applying software fixes, or stop using buggy feature X. But these days, the smart CEs are mostly dead, retired, or laid-off, and their replacements are often contracted out people who just know how to swap out parts. (Or have an incentive for you to have more failures, since part swaps == money.)
If you as an admin actually service your stuff, you'll notice failure patterns and actually troubleshoot the stuff.
I can't express how happy I am to see this post. I made to decision to move all our database servers to Intel 510's 120gb months ago and it was difficult to find any data on long term use in an enterprise environment for any SSD's let alone consumer ones. Ordered several new 520's last week as spares and to replace the drives in our web servers, looks like it was a good choice after all.
Then you might also enjoy this review:
http://www.storagereview.com/intel_ssd_520_enterprise_review
I found the write speed improvements from overprovisioning the SSD 20% especially interesting. Although probably irrelevant if your webservers are mostly doing reads.
I found the write speed improvements from overprovisioning the SSD 20% especially interesting. Although probably irrelevant if your webservers are mostly doing reads.
Thanks for the link. This will come in handy since were moving to 520's across the board including our database servers eventually.
Problem with this article is they're not considering whether their write load is justifiable. Why are they writing 15x as much data as they read?
Anand wrote this in response to the question: "Statistics are pretty beefy (they are one of our enterprise workloads after all) as we're tracking requests to all articles published. Couple a few hundred thousand readers per day with multiple article requests per reader and that's a lot of traffic to keep track of."
Sure it's a lot of traffic but why do you need to write it to an SSD? That's something you can easily offload to a slow database and/or file server. And once you do, what does your write load look like? If it's dramatically lower then it means your conclusions need to be revisited.
Anand wrote this in response to the question: "Statistics are pretty beefy (they are one of our enterprise workloads after all) as we're tracking requests to all articles published. Couple a few hundred thousand readers per day with multiple article requests per reader and that's a lot of traffic to keep track of."
Sure it's a lot of traffic but why do you need to write it to an SSD? That's something you can easily offload to a slow database and/or file server. And once you do, what does your write load look like? If it's dramatically lower then it means your conclusions need to be revisited.
Not to mention storing page view data in a RDBS.
What is a better solution for a high traffic site than tracking page view data into an RDB? Log files other than the built in server logs? NoSql? I'm genuinely curious because my work site is currently tracking into Sql.
NoSQL would be what I would go for since this is the type of thing that Redis and similar excel at. Any way you can prevent writes per page view the better off you'll be. Redis gets you speeds similar to memcached but with some stuff you'd expect from a RDBS (durability, replication, etc). It's great for logging/analytics.
"Each drive in the first DB server has seen around 570GB of writes in 9 days, or roughly 63GB/day. The drives in the second DB server have gone through 1.03TB of writes in the same period of time or 114GB/day."
They're writing an incredible amount of data for what amounts to a fairly standard article/comment/forum site (which are typically very read heavy).
"Each drive in the first DB server has seen around 570GB of writes in 9 days, or roughly 63GB/day. The drives in the second DB server have gone through 1.03TB of writes in the same period of time or 114GB/day."
They're writing an incredible amount of data for what amounts to a fairly standard article/comment/forum site (which are typically very read heavy).
The question then is: when are you planning on replacing it. If you are going to replace it within the lifespan of a 320 (maybe for more capacity, or because new generations will be faster), you are better off sticking with a 320.