[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