[mythtv-users] warning for anyone with western digital green drives
Warpme
warpme at o2.pl
Wed Jan 11 21:29:54 UTC 2012
Hi,
At beginning I want to underline, Ron's OP make this mailing-list really
nice source of knowledge.
Thx for this.
Inspired by OP, last days I was experimenting little with SDD in my
MythTV system (BE server).
Result were surprising enough that I decide to post them here.
My BE is 880G based mobo with AMD235E CPU, 4G RAM, and base storage via
2x2TB WD green.
First HDD is OS+DB and hosts HD movies.
Second HDD is /myth.
OS is Arch derivative.
All FE are based on ATOM1 and are disk-less PXE booted.
OS is minimyth derivative.
MythTV is v0.25pre-4055-gf9f8b71-dirty-20120111
In my test 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.
Some notes:
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 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.
Moving from 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.
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 slow HDD like WD Green is working
really nice even with ATOM CPU. (86 progs EPG loads in aprox 0.4sec.
390+ 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: Sorry not sending this mail with proper thread-id. I had some
problems with mailer software and old posts were lost, so I can't get
reference ID.
BTW2: I replaced my desktop HDD (Caviar Black 1TB) with this SSD. Here
SSD plainly SCREAMS.
I.e launching program or restoring it's window are practically
indistinguishable.
More information about the mythtv-users
mailing list