[mythtv-users] DB Tuning (Was: Replace backend 3.5 system disk with 2 2.5 raid1?)

[Simon Hobson]

Mike Carron <jmcarron at starstream.net> wrote:

>> mysqltuner.pl is a useful tool.
> Thanks. I noticed that mysqltuner.pl doesn't claim compatibility with MySQL 5.5. What problems, if any, might that cause?

No idea !
I wouldn't have thought all that much would have changed, so I'd expect the results to still be valid. But then I'm not a MySQL expert.

> Also, you mentioned "oodles" of RAM but did not identify how much is an "oodle."

I think there are several oodles to a bucketload, and several bucketloads to a wow :-)

It's one of those "how long is a piece of string ?' type questions. My own backend has 2G of RAM, and at the moment (it's currently recording one radio stream from DVB-T, aka Freeview) I get these stats from top :

Mem:   2027944k total,  1854508k used,   173436k free,    27108k buffers
Swap:  2097144k total,    53636k used,  2043508k free,  1145296k cached

I don't think Myth itself takes a lot of memory - it's more the stuff that goes with it : getting your TV listings, the database when it's being pushed during a reschedule, commflagging, transcoding, ... If you don't commflag or transcode then I suspect 1G would be adequate, if you do either of those then more memory has benefits.

One benefit of more RAM is if you run tasks that access recently recorded material. If that material is still in cache memory then there is no disk overhead in accessing it, but if it's been flushed then it'll have to be read back in which means more disk I/O and more disk seeking (cf earlier discussions in this thread). The more memory you have, the more recorded material you can keep in cache.

The other benefit of more memory is that you can safely tune MySQL to use more - note that my tuning allows MySQL to use up to about 1G max. It won't hold onto that if it's not using it, but it can use it if it needs to. If you only had 1G of RAM then you'd need to be a bit more conservative - with a tradeoff in terms of disk usage. What you really need to avoid is any significant swapping, that's a real performance killer.

There is a saying that you can't have too much RAM. In general that's true, though I have found a situation* where too much RAM breaks a system. On most systems, the cost difference between 1G, 2G, and 4G makes 4G (or more) a bit of a "no brainer".

* Tried running the backend as a Xen guest with PCI passthrough for the tuners. Found that if the host had more than 4G RAM, the tuners didn't work.