SSDs

Tue Apr 9 20:56:10 MST 2013

Toms Hardware did a great deal of this sort of testing. when we looked at
it i used some of their bench-marking tools. specifically iometer to mimic
our applications workload and used that as a baseline.

be a fun project if i had the money to do it. but toms hardware might have
you some money with their results ;-)

On Tue, Apr 9, 2013 at 8:37 PM, Lisa Kachold <lisakachold at obnosis.com>wrote:

> Hey Bryan,
>
> As usual,  your opinion backed with long experience is beneficial to the
> Unix/linux/enterprise IT community.
>
> With all the and misinformation about disk performance comparisons with
> SSDs,  I am Interested to talk to those actually doing the benchmarks.  I
> have peers in the storage blog community who happily parrot this study or
> that, but as I chimed in initially, I have not had sufficient SSDs to run
> my own tests comparable to standard enterprise performance tests.
>
> *I would be interested to see more specifics related to your testing,
> specifically drive size and manufacture, test tools, Trim, smartd, and
> other kernel settings, including distro version and 3rd party or
> manufacturer drivers?  *
>
> This would be great "blog" material actually, so I hesitate to request it
> for PLUG Email List server ingestion alone.  But it's certainly timely in
> an arena with a good deal of misinformation?
>
> I suggest anyone looking into enterprise storage benefits of SSD's look at
> the FAQ's from SanDisk, Crucial or OCZ and *read between the lines
> carefully*.
>
> Enterprise Solid State drives have yet to be widely available for the
> shops which I contract.  While I am not specifically a storage engineer, I
> like many linux/unix administrators must wade through a great deal of
> industry chaff in order to get to the core of this relatively new
> technology.  It's not too rare anymore that I have to recommend a solution
> and had to clear up a great deal of confusion for a shop with a gung ho
> hobby-ist type Entrepreneur-type hell bent on SSD drives in a pair of Dell
> R610's which were joining a farm of PE1850, PE1950, PE2850, PE2950's which
> were purchased used (Westech Recyclers).  The discussion came down to
> evaluation of a multitude of studies of SSD's compared with Controller
> based DELL RAID and no appreciable benefit (to offset a huge financial buy
> up option with Dell).  I have since, worked with 2 other large shops with
> the where with all to purchase SSDs where the storage and server architects
> agreed that SSDs were not yet cost effective in a blade or controller card
> enterprise environment.
>
> Since I use Fedora for my desktop (Dell/Sony/HP systems), I referred to
> https://www.modnet.org/fedora-optimization-performance-ssd/ which
> discusses in fair detail Trim Optimization and Performance.  Note: If you
> use Ubuntu see:http://askubuntu.com/questions/18903/how-to-enable-trim.
>
>  What I have seen with one Dell Inspiron 17R with "add on" 32GB SSD Dell
> "Special option", when booted into Linux Performance BenchMark , no
> significant read/write speed improvement was realized.  As I mentioned,
> this system must remain Windows 7 (due to Enterprise contracting
> requirements), where the SSD performance is SLUG SLOW!
>
> Here's what I did and what I found:
>
> Test System:
>
> Dell Inspiron 17R 3rd Generation Intel® Core™ i7-3630QM (6MB cache, up to
> 3.4Ghz)
>
> 1TB 5400RPM SATA HDD + 32GB mSATA SSD w/ Intel Smart Response
>
> Test Medium/Process:
>
> Clean boot into knoppix - manual mount of 32GB SSD drive, run sudo hdparm
> -t /dev/sda
>
> Dell Solid State Drive (crucial?) did not perform any faster than the 1TB
> SATA.
>
> Other Optimization Considerations (which don't apply in my test model due
> to simple boot iso testing appear below in addition to the Trim
> Optimization)
>
> *NoAtime Tweak  *
>
> By default Linux will write the last accessed time attribute to files.
> This can reduce the life of your SSD by causing a lot of writes. The
> noatime mount option turns this off.
> Open your fstab file:
> sudo vi /etc/fstab
>
> Ubuntu uses the relatime option by default. For your SSD partitions
> (formatted as ext3), replace relatime with noatime in fstab.  To effect
> changes a reboot is required.
>
> *Ramdisk Tweak*
> Using a ramdisk instead of the SSD to store temporary files will speed
> things up, but will cost you a few megabytes of RAM.
> Open your fstab file:
> sudo vi /etc/fstab
>
> Add this line to fstab to mount /tmp (temporary files) as tmpfs (temporary
> file system):
> tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
>
> Reboot to affect changes. Running df, you should see a new line with /tmp
> mounted on tmpfs:
>
> tmpfs 513472 30320 483152 6% /tmp
>
> *Firefox Cache Tweak*
> Firefox puts its cache in your home partition. By moving this cache in RAM
> you can speed up Firefox and reduce disk writes. Complete the previous
> tweak to mount /tmp in RAM, and you can put the cache there as well.
> Open about:config in Firefox. Right click in an open area and create a new
> string value called browser.cache.disk.parent_directory. Set the value to
> /tmp.
>
> *I/O Scheduler Tweak*
> An I/O scheduler decides which applications get to write to the disk when.
> Since SSDs are different than a spinning hard drive, not all I/O schedulers
> work well with SSDs.
> The default I/O scheduler in Linux is cfq, completely fair queuing. cfq
> works well on hard disks, but it's known to cause problems on Eee PC’s SSD.
> While writing a large file to disk, any other application which tries to
> write hang until the other write finishes.
>
> The I/O scheduler can be changed on a per-drive basis without rebooting.
> Run this command to get the current scheduler for a disk and the
> alternative options:
> cat /sys/block/sda/queue/scheduler
>
> You’ll probably have four options, the one in brackets is currently being
> used by the disk specified in the previous command:
> noop anticipatory deadline [cfq]
>
> Two are better suited to SSD drives: noop and deadline. Using one of these
> in the same situation, the application will still hang but only for a few
> seconds instead of until the disk is free again. Not great, but much better
> than cfq.
>
> Here’s how to change the I/O scheduler of a disk to deadline:
> echo deadline > /sys/block/sda/queue/scheduler
>
> (Note: kernel change commands needs to be run as root, but sudo does not
> work with it on various distros. Run sudo -i if you have a problem to get a
> root prompt.)
>
> Of course you will replace sda with the disk you want to change, and
> deadline with any of the available schedulers. This change is temporary and
> will be reset when you reboot.
>
> If you’re using the deadline scheduler, there’s another option you can
> change for the SSD. This command is also temporary and also is a per-disk
> option:
> echo 1 > /sys/block/sda/queue/iosched/fifo_batch
>
> You can apply the scheduler you want to all your drives by adding a boot
> parameter in GRUB. The menu.lst file is regenerated whenever the kernel is
> updated, which would wipe out your change. Instead of this way, I added
> commands to rc.local to do the same thing.
>
> Open rc.local:
> sudo gedit /etc/rc.local
>
> Put any lines you add before the exit 0. I added six lines for my Eee PC,
> three to change sda (small SSD), sdb (large SSD), and sdc (SD card) to
> deadline, and three to get the fifo_batch option on each:
> echo deadline > /sys/block/sda/queue/scheduler
> echo deadline > /sys/block/sdb/queue/scheduler
> echo deadline > /sys/block/sdc/queue/scheduler
> echo 1 > /sys/block/sda/queue/iosched/fifo_batch
> echo 1 > /sys/block/sdb/queue/iosched/fifo_batch
> echo 1 > /sys/block/sdc/queue/iosched/fifo_batch
>
> Reboot to run the new rc.local options.
>
>
> *Kopt Tweak*
> It’s possible to add boot parameters to menu.lst that won’t be wiped out
> by an upgrade. Open menu.lst  (Backup this file before you edit it):
> sudo vi /boot/grub/menu.lst
>
> The kopt line gives the default parameters to boot Linux:
> # kopt=root=UUID=6722605f-677c-4d22-b9ea-e1fb0c7470ee ro
>
> Leave this line commented and add any extra parameters.  To change the I/O
> scheduler, use the elevator option:
> elevator=deadline
>
> Append that to the end of the kopt line. Save and close menu.lst.  Then
> run update-grub to apply your change to menu:
> sudo update-grub
> [end update]
>
> *Quick and Dirty Performance Test*
> Using hdparm to test the read performance of your disk:
> sudo hdparm -t /dev/sda
>
> See Ubuntu: https://wiki.ubuntu.com/MagicFab/SSDchecklist
>
> On 9 Apr 2013 11:30, "Bryan O'Neal" <Bryan.ONeal at theonealandassociates.com>
> wrote:
>
>> It depends on the drive of course, but we have found them to be
>> significantly faster offering over 10X IOPS on average, This
>> is comparison to buffered 15K enterprise dries.
>>
>>
>> On Tue, Apr 2, 2013 at 1:24 PM, Lisa Kachold <lisakachold at obnosis.com>wrote:
>>
>>> I have also found that in deference to their claims some of the SSDs are
>>> SLOWER than regular enterprise drives.
>>> I believe this new technology leaves a lot to be desired.
>>>
>>>
>>> On Tue, Apr 2, 2013 at 12:27 PM, Derek Trotter <expat.arizonan at gmail.com
>>> > wrote:
>>>
>>>> I have a question about SSDs.  I've read that they like the USB thumb
>>>> drives can be written to a certain number of times before they fail.  What
>>>> is the expected lifetime of an SSD?  They're terribly expensive if they're
>>>> only going to last 2 or 3 years.
>>>>
>>>> Derek
>>>>
>>>> --
>>>> "I get my copy of the daily paper, look at the obituaries page, and if
>>>> I’m not there, I carry on as usual."
>>>>
>>>> Patrick Moore
>>>>
>>>> ------------------------------**---------------------
>>>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.**org<PLUG-discuss at lists.phxlinux.org>
>>>> To subscribe, unsubscribe, or to change your mail settings:
>>>> http://lists.phxlinux.org/**mailman/listinfo/plug-discuss<http://lists.phxlinux.org/mailman/listinfo/plug-discuss>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> (503) 754-4452 Android
>>> (623) 239-3392 Skype
>>> (623) 688-3392 Google Voice
>>> **
>>> it-clowns.com
>>> Chief Clown
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>

-- 
A mouse trap, placed on top of your alarm clock, will prevent you from
rolling over and going back to sleep after you hit the snooze button.

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20130409/7c4f85f6/attachment.html>