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 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" > 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 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 >> > 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@lists.phxlinux.**org >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> 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@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@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@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