[mythtv-users] MySQL on SSD 99% Utilization
Brian Long
briandlong at gmail.com
Thu Feb 3 18:45:26 UTC 2011
On Thu, Feb 3, 2011 at 1:38 PM, Matthew McClement <mythtv at macker.co.uk>wrote:
> On 02/03/2011 05:43 PM, Raymond Wagner wrote:
> > On 2/3/2011 12:37, Matthew McClement wrote:
> >> On 02/03/2011 05:27 PM, Raymond Wagner wrote:
> >>> On 2/3/2011 11:40, Brian Long wrote:
> >>>> The CPUs are doing almost nothing so it appears the MySQL updates
> >>>> being performed during a commflag are screwing with the SSD. Is it
> >>>> generally a bad practice to put MySQL on a SSD? I figured it would
> >>>> provide a nice fast DB and keep my DB separate from my recording
> >>>> disks, but I guess I was wrong.
> >>> Looking at reviews on the SSDNow V 30GB, the one thing that stands out
> >>> is awful random read/write performance. Even still, it should be far
> >>> better than a disk drive is capable of.
> >> Anands benchmarks show the SSDNow V 30GB is the same speed as a
> >> Velociraptor at 4K random writes, which is pretty terrible for a SSD:
> >>
> >> http://www.anandtech.com/bench/Product/155?vs=182
> >
> > That metric just looks wrong. It looks like they're buffering writes to
> > something other than the drive, and that something else is actually what
> > is bottlenecking. That's the only way to account for the discrepancy
> > between reads and writes. Measuring write buffer speed is meaningless
> > unless that write buffer is battery backed and recoverable.
>
> Eh? SSD's are significantly slower at writes than reads, especially if
> you're writing to a non-GC'd cell, which with how the Toshiba controller
> handles TRIM is entirely possible(GC isn't continuous but rather seems
> to be demand triggered). If you then add non-aligned sub-page sized
> writes, things can get bad pretty quickly.
>
> It's buffering and other tricks which make SSD's faster today over the
> early versions, rather than slower.
>
> And it's not like that result is an oddity. Just look at any benchmark
> for the early JMicron based SSDs to see SSDs that were often *slower*
> than hard disks at random writes.
>
I would have thought Fedora 13 would have aligned it properly, but I guess
it's off a little.
$ sudo parted /dev/sdg print
Model: ATA KINGSTON SSDNOW (scsi)
Disk /dev/sdg: 30.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary ext4 boot
2 525MB 30.0GB 29.5GB primary lvm
I upgraded from F13 to F14, but I wonder if a re-install might be better?
All my data (except MySQL) is in a separate volume group which houses my
RAID-6 MD array. Since I've probably written more than 30GB to the SSD
drive by installing F13, then F14, should I try to condition the drive? I
knew this drive's performance wasn't similar to my desktop's Intel G2 SSD,
but I didn't think it would crawl so badly.
I don't think changing the IO scheduler for the whole system is necessarily
wise since it would affect my recording drives as well. I might just move
/var/lib/mysql to the MD array and be done with it. :-)
/Brian/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20110203/4b856fae/attachment.htm>
More information about the mythtv-users
mailing list