A Look at Enterprise Performance of Intel SSDs
anandtech.com
anandtech.com
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.
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...).
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 found the write speed improvements from overprovisioning the SSD 20% especially interesting. Although probably irrelevant if your webservers are mostly doing reads.
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.
"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).