[mythtv-users] SSD for speed up FE/BE

Thu Jun 7 06:55:31 UTC 2012

On 6/6/12 11:52 PM, Josu Lazkano wrote:
> Hello all,
>
> I am thinking on buy a little SSD drive to speed up my Nvidia ION Atom
> FE/BE system. Actually I host MySQL data directory on 2.5 HDD
> (5400rpm) EXT4 disk. I have some questions about SSD setup.
>
> 1. Which is the best option to host MySQL datadir? EXT3? EXT4? XFS?
> Mount options?
> 2. Must I host other files on the SSD disk? channel icons? logs?
>
> I am planning on buy a little disk, maybe 4 or 8GB. I will appreciate
> any help, thanks and best regards.
>
> --
> Josu Lazkano
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
Josu,
Sometime ago I was experimenting little with SDD in my MythTV system 
(mythtv backend).
Result were surprising enough that I decide to recall them them here.

My BE is 880G based mobo with AMD235E CPU, 4G RAM, and base storage on 
2x2TB WD green.
First HDD is OS+DB and hosts HD movies.
Second HDD is /myth volume.
OS is ArchLinux derivative.

All FE are based on ATOM1 and are disk-less PXE booted.
OS is minimyth derivative.

MythTV on tests was v0.25pre-4055-gf9f8b71-dirty-20120111

In my SSD tests I replaced OS+DB drive to SSD (Samsung 830 series, 64G 
model).
SSD was with Ext4, discard, noatime, barriers=off. CHS aligned to 32/32.

General observations:
 From 4G RAM, kernel allocated 2,7G to buffers.
I can expect this level in storage hierarchy (buffers) will be slower 
that RAM but faster than any next in hierarchy storage level (physical 
mass storage).
Also I configured 32M query cache to mysql in hope that DB reads fill be 
mainly from cache. Other parameters were set to mysqltuner.pl suggestions.
I configure /tmp as tempfs in hope that all temp SQL tables will be 
written-read from RAM based mass storage.

After move HDD to SSD:

Results:
Qualitative:
-On FE I practically didn't notice any subjective speed-up.
-Only area where speed-up is seen is mythweb (was instant, with SSD is 
flashy)
-I can definitely say: it is NOT a case where SSD-based system was slow 
like HDD-based one. It is a case where HDD-based system is the same fast 
like SSD (for justification of such statement pls go to end of this post).

Quantitative:
Here are OS boot & scheduling comparisons:

HDD boot:
Jan 11 14:36:54 Startup finished in 3s 54ms 736us (kernel) + 56s 995ms 
395us (userspace) = 1min 50ms 131us.
(I have so long userspace as I add 45sec zoneminder start delay)

HDD scheduling:
2012-01-11 14:53:42.959000 I Scheduled 381 items in 5.7 = 3.44 match + 
2.22 place
2012-01-11 15:46:22.516929 I Scheduled 379 items in 5.8 = 3.50 match + 
2.27 place
2012-01-11 15:51:17.644414 I Scheduled 379 items in 5.9 = 3.55 match + 
2.36 place
2012-01-11 15:56:16.214845 I Scheduled 379 items in 5.9 = 3.55 match + 
2.37 place
2012-01-11 15:57:53.363886 I Scheduled 379 items in 2.4 = 0.00 match + 
2.35 place
2012-01-11 15:59:50.008540 I Scheduled 379 items in 2.4 = 0.00 match + 
2.36 place
2012-01-11 16:07:13.492971 I Scheduled 378 items in 6.0 = 3.74 match + 
2.26 place
2012-01-11 16:11:16.104133 I Scheduled 378 items in 5.9 = 3.73 match + 
2.21 place
2012-01-11 16:16:16.588279 I Scheduled 378 items in 5.7 = 3.55 match + 
2.20 place

SSD boot:
Jan 11 11:57:26 Startup finished in 4s 541ms 296us (kernel) + 52s 835ms 
494us (userspace) = 57s 376ms 790us.

SSD schedulling:
2012-01-11 12:07:04.334242 I Scheduled 383 items in 6.0 = 3.56 match + 
2.39 place
2012-01-11 12:10:03.098568 I Scheduled 382 items in 2.4 = 0.00 match + 
2.36 place
2012-01-11 12:11:15.145393 I Scheduled 382 items in 5.8 = 3.47 match + 
2.36 place
2012-01-11 12:16:16.925119 I Scheduled 382 items in 5.9 = 3.53 match + 
2.35 place
2012-01-11 12:21:16.627705 I Scheduled 382 items in 5.8 = 3.47 match + 
2.33 place
2012-01-11 12:26:14.412831 I Scheduled 382 items in 5.9 = 3.51 match + 
2.35 place
2012-01-11 12:31:16.768138 I Scheduled 382 items in 5.9 = 3.50 match + 
2.39 place
2012-01-11 12:35:31.710289 I Scheduled 382 items in 6.0 = 3.55 match + 
2.44 place

My conclusions:
1.In case of my system build-in-kernel disk buffering is so effective 
that even significant speedup of next level storage hierarchy (HDD->SSD) 
is totally masked by kernel buffering.
2.Big enough MySQL caches quite effectively masks speedups in mass-storage.
3.Recordings rescheduling speed is directly correlated to CPU (going 
from Celeron 3,46G to AMD 235E changed reschedule time from 60s to 18s).
4.For rescheduling speed-up, next, after CPU upgrade & mysql caches, is 
moving /tmp to tempfs (noticeable speedup 18s->6s).
5.Current MythTV system based on quite standard HDD like WD Green is 
working really nice even with ATOM CPU. (i.e.86 progs EPG list loads in 
aprox 0.2-0.4sec; showing 400+ recordings list is instant (in sense that 
there is no time to show loading progress dialog).

Summarizing:
Speaking in economy: HDD->SSD marginal utility increase is in my case 
was ABSOLUTELY not worth of SSD investment.

Before SSD spending decision I'm strongly recommending:
-buy more RAM for having huge as possible kernel disk buffers
-move /tmp to tempfs
-allocate 32MB or more for MySQL query cache (and other parameters 
accordingly to http://mysqltuner.pl/)
With above it is highly probable that You will get MythTV system where 
HDD->SSD upgrade will absolutely not worth the money (and allows You 
spent those money elsewhere - with much higher utility).

-br

BTW: I replaced my desktop HDD (Caviar Black 1TB) with this SSD. I'm on 
MAC OSX 10.7.3.
Here SSD plainly SCREAMS.
I.e launching program or restoring it's window are practically 
indistinguishable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: warpme.vcf
Type: text/x-vcard
Size: 83 bytes
Desc: not available
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120607/9ef06417/attachment-0001.vcf>