[mythtv-users] Bad mysql performance -- huge oldrecorded -- joins without index

Simon Hobson linux at thehobsons.co.uk
Wed Jun 8 14:42:59 UTC 2016

"Michael T. Dean" <mtdean at thirdcontact.com> wrote:

> There is one way to improve scheduler performance outside of MythTV--4) throw more/better resources at it:  get better/more CPU and/or RAM and/or file system performance (which can have a huge impact if using things like barriers or file systems that take huge amounts of I/O resources when doing things like deleting large files and when the user didn't enable slow deletes in MythTV, like he should have).

So the first step is, as the OP seems already to be doing, tune MySQL to the load and use as much RAM as "makes sense" - there is a point where adding RAM makes little additional difference, but initially a bit more RAM can make a huge difference.

I found that putting the databases on SSD made a huge difference. The drive I was using went bad (hmm, at which point I remember I've still got it's replacement sitting around) and I went bad to spinning rust - the difference in time taken when working in MythWeb is quite noticeable. With SSD the system could reschedule before redrawing the upcoming recordings page, back on disks it doesn't - so clicking "don't record" doesn't remove a showing until after the following page update. And only using part of the SSD will mean it can keep up write performance for longer as it can keep a larger cache of erased blocks - or if the OS & filesystem supports TRIM then just keeping free space in the filesystem is enough (AIUI).
Obviously YMMV and the number of factors affecting performance is "quite large".

More information about the mythtv-users mailing list