

A Look at Enterprise Performance of Intel SSDs - yread
http://www.anandtech.com/show/5518/a-look-at-enterprise-performance-of-intel-ssds

======
latch
So it costs 2x more [than a 320], performs the same, but gets you up to an
order of magnitude more endurance.

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.

~~~
philjohn
Plus, if you overprovision a 320 you not only increase IOPS, but also increase
endurance.

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

~~~
Duff
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.

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

~~~
btb
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.

~~~
mmx
Thanks for the link. This will come in handy since were moving to 520's across
the board including our database servers eventually.

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

~~~
jonknee
Not to mention storing page view data in a RDBS.

~~~
misterbwong
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.

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

