[ale] SSD speeds

Lightner, Jeff JLightner at dsservices.com
Wed Jul 2 13:28:09 EDT 2014


With appropriate budget and redundancy SSD will definitely outperform mechanical drives on both writes and reads.

The main issue with SSD deals with burn in where items stored in certain memory bits can't be written to again so over time the SSD can degrade.   Most of the better manufacturers put in some sort of wear leveling to prevent this from being an issue soon.   So long as you have redundant systems under maintenance it isn't a major concern because if the disk can't be written to you can get it replaced.

We have a disk array with some 7 TB of SSDs (200 GB each) that we've been using since 2011 and have thoroughly enjoyed the performance we get for our main ERP database.  In fact with that array our main performance constraint was the cache the array itself has (as opposed to individual disks) was impeding writes to SSD because it was shared with the mechanical drives in the same array.   Luckily this array allowed for cache partitioning and we were quickly able to separate the cache used by the SSDs from that used by all the rest of the drives.

We also have bought a few of the FusionIO SSDs on HBA cards (rather than disk form factors) for specific workloads and they perform well also.   My only complaint is that we do NOT have redundant cards and when we made the mistake of using a single one as main data storage it overheated and fried the firmware chip.   Fusion's ID of support doesn't include 24x7 with local depots in major cities like Atlanta.   Just getting them to ship us a replacement on a Saturday via FedEx when we had that issue was like pulling teeth.   The moral is:
-Either be sure that what you're using the non-redundant storage for is ephemeral (e.g. temporary files or temporary database space) you can afford to lose
-OR-
-Be sure to have redundancy (e.g. RAID1 by getting 2 or more of the SSDs).  After the FusionIO event most of the reading I did suggested most folks using them ARE buying them in pairs.

We have also gotten a couple of Dell's recently with internal SSD "disks" but they're new enough that I can't say how good (or bad) they might be.   We did NOT get redundancy for those and I've already complained about these being single points of failure.





-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Chris Fowler
Sent: Wednesday, July 02, 2014 12:23 PM
To: Atlanta Linux Enthusiasts
Subject: [ale] SSD speeds

Yesterday I received two systems we ordered and installed CentOS 6.5 on them.  I am ignorant of SSD speeds and these systems have 2 128gb/ea I'm running as RAID1 via mdtools. I'm amazed at the speed compared to the SATA II/III drives I've been using.

In the past we've used drives because we wanted space.  In this project I would be happy with a 20GB SSD so space is not an issue.  I decided to give it a try. I like them.

Are write speeds slower that standard drives?  Is there any reason I should not move forward with this model of using SSD in our systems vs real drives?

I do have rant about CentOS 6.5 text install.  I've googled it and I understand why it is like this I just hate that I could do this in 5, but not 6.

I've installed many CentOS 5 systems around the world.  In some cases I need to reinstall them.  I may be going to an older Fedora system to
CentOS.  Or I may have corruption.   I may even install new hardware.
What I do is create a serial bootable CD.  I then place a device on the server's serial port, connect remotely to it, and have the customer boot the CD.  I can now install in text mode remotely.  If I'm working on a system that has already been loaded I'll copy vmlinuz and initrd.img to it, modify grub meny.lst and then boot that entry.

This works on CentOS 6 up until I get to partitioning disks.  You can not do custom partitioning any more via text.  I had to install the system in my lab last night via VNC.  This complicates these remote installs because I have to figure out a way to gain remote IP access.  I think the only solution is to create a kickstart file.  On a new system that the customer purchases I will need to know about the drives before I can create the file to partition them.  Forcing a graphical install just sucks and to me that is anti-server and pro-desktop.

Just my rant, ignore it. :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140702/65e7d10d/attachment.html>
_______________________________________________
Ale mailing list
Ale at ale.org
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer

__________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail may contain privileged

or confidential information and is for the sole use of the intended

recipient(s). If you are not the intended recipient, any disclosure,

copying, distribution, or use of the contents of this information

is prohibited and may be unlawful. If you have received this electronic

transmission in error, please reply immediately to the sender that

you have received the message in error, and delete it. Thank you



More information about the Ale mailing list