[mythtv-users] MySQL on SSD 99% Utilization

[Matthew McClement]

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.

Matt