[mythtv-users] Raid Performance Tweaking

[Blammo]

On 7/6/06, Dean Wilson <dean.k.wilson at gmail.com> wrote:
> I know that many of us are interested in Raid, but don't really know
> the best configuration for a myth setup.  I, like many others here, am
> interested in Raid5, and would like it to perform optimally for (very)
> large files.
>
> I've read http://www.tldp.org/HOWTO/Software-RAID-HOWTO-9.html, which
> gets into chunk and block size performance testing, but doesn't use
> chunks above 32K.  I would think that a larger chunk size would be
> ideal for myth, as it uses exceedingly large files.
>
> I figured I'd use bonnie to measure performance gains/losses, since
> that's what the howto used.  Obviously I'll play with different
> chunk/block size combinations, and will report my findings.  But I'm
> curious to know if anyone out there would be interested in any other
> specific tests?  If so, let me know -- I'll try to include them, and
> will put together a web page with the results I find.

Now that this thread has gotten completely off-track, let me try to
answer the original guy, just with what I found. Here's some things
you can tune to help your performance under mythTV. Others (Jarod etc)
I'm sure can comment more succintly than I ...

1. RAID cluster size: usually choices like 64k, 256k, 512k, etc. The
largest my card will support is 256k and that's where mine is set. I
saw better multithread performance with a larger size. Less thrashing
back to the disk(s)

2. Filesystem : File Systems like XFS and JFS have better delete,
burst, directory handling, and large file performance than EXT3. The
'net benchmarks report this, and I confirmed for myself, and made my
choice.Trying to explain to your wife why mythtv hangs for 15 seconds
while deleting a 16gig program is not something you want to have to do
more than once. XFS deletes in sub 1 second.

3. IO Scheduler: (Lots of good info here :
http://www.wlug.org.nz/LinuxIoScheduler) Changes the way in which the
OS doles out IO performance. I've found for me, the best performance
from the "deadline" scheduler, which gives even timeslices to each
thread, which seems to avoid starving any one thread.

4. Performance testing: In the beginning people use HDParm, which is a
good way to get started, but is very inconsistant. You then graduate
to bonnie++ which is a great drive benchmarking tool. When I'm
benchmarking the drive, I usually do the first pass in  single-user
mode to avoid any other process contention, record that, then
benchmark the rest in multi-user to get a baseline.

On this page you're making, I'd love to have somewhere to share my
results, others, etc to get an idea if our systems are performing
where they should be, and to help make decisions about upgrades, etc.