<div class="gmail_quote">On Thu, Feb 3, 2011 at 1:38 PM, Matthew McClement <span dir="ltr"><<a href="mailto:mythtv@macker.co.uk">mythtv@macker.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 02/03/2011 05:43 PM, Raymond Wagner wrote:<br>
> On 2/3/2011 12:37, Matthew McClement wrote:<br>
>> On 02/03/2011 05:27 PM, Raymond Wagner wrote:<br>
>>> On 2/3/2011 11:40, Brian Long wrote:<br>
>>>> The CPUs are doing almost nothing so it appears the MySQL updates<br>
>>>> being performed during a commflag are screwing with the SSD. Is it<br>
>>>> generally a bad practice to put MySQL on a SSD? I figured it would<br>
>>>> provide a nice fast DB and keep my DB separate from my recording<br>
>>>> disks, but I guess I was wrong.<br>
>>> Looking at reviews on the SSDNow V 30GB, the one thing that stands out<br>
>>> is awful random read/write performance. Even still, it should be far<br>
>>> better than a disk drive is capable of.<br>
>> Anands benchmarks show the SSDNow V 30GB is the same speed as a<br>
>> Velociraptor at 4K random writes, which is pretty terrible for a SSD:<br>
>><br>
>> <a href="http://www.anandtech.com/bench/Product/155?vs=182" target="_blank">http://www.anandtech.com/bench/Product/155?vs=182</a><br>
><br>
> That metric just looks wrong. It looks like they're buffering writes to<br>
> something other than the drive, and that something else is actually what<br>
> is bottlenecking. That's the only way to account for the discrepancy<br>
> between reads and writes. Measuring write buffer speed is meaningless<br>
> unless that write buffer is battery backed and recoverable.<br>
<br>
</div>Eh? SSD's are significantly slower at writes than reads, especially if<br>
you're writing to a non-GC'd cell, which with how the Toshiba controller<br>
handles TRIM is entirely possible(GC isn't continuous but rather seems<br>
to be demand triggered). If you then add non-aligned sub-page sized<br>
writes, things can get bad pretty quickly.<br>
<br>
It's buffering and other tricks which make SSD's faster today over the<br>
early versions, rather than slower.<br>
<br>
And it's not like that result is an oddity. Just look at any benchmark<br>
for the early JMicron based SSDs to see SSDs that were often *slower*<br>
than hard disks at random writes.<br></blockquote><div><br>I would have thought Fedora 13 would have aligned it properly, but I guess it's off a little.<br><br>$ sudo parted /dev/sdg print<br>Model: ATA KINGSTON SSDNOW (scsi)<br>
Disk /dev/sdg: 30.0GB<br>Sector size (logical/physical): 512B/512B<br>Partition Table: msdos<br><br>Number Start End Size Type File system Flags<br> 1 1049kB 525MB 524MB primary ext4 boot<br>
2 525MB 30.0GB 29.5GB primary lvm <br></div></div><br>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.<br>
<br>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. :-)<br><br>
/Brian/<br>