[mythtv-users] Scheduler runs slowly causes backend to lock up

[Paul Netherwood]

> ....
> > I'm beginning to wonder if its just coincidental that the time increase happened near a version upgrade but what was really happening is that a temporary table that could fit into memory was now being moved onto disk.
> 
> Seems possible.  Note that most current distros specify
> tmpfs for /tmp, and /tmp is where mysql places its
> temporary tables (by default).  This mitigates against
> most temporary table overflows to disk if you have the
> memory available.  If your /tmp is still a real disk, or
> your tmpfs swaps due to memory constraints, things
> can get slower without appropriate tuning.  200 seconds
> sounds extreme, but it would depend on your specific
> environment.

I'm on Ubuntu 14.04. Mysql temp area is /tmp is on disk but the disk is an SSD. I was wondering about moving /tmp to tmpfs. I've got 4GB memory and 4GB swap. My current tmpfs is automatically allocated 384M by the OS. I was wondering if that would be enough and if it was to move the mysql tmp area to tmpfs? I believe tmpfs if full will overflow into swap.

> 
> > It occurred to me that it has been ages since I had a look at my mysql config and did a bit of tuning. After a bit of tweaking I was able to get my place times from well over 200 seconds to just a over a second!
> 
> Should I reopen the can of discontent and mention that the
> current need for user tuning is certainly one reason that
> embedding the DB (and its configuration) will be goodness
> for the majority who just want a toaster?

I think its quite handy having access to the database directly. Its really handy for things like tidyups directly in sql in the channel table after a rescan. Another examp-le is that I use Nagios to alert me of system failures and its really handy to have queries for various status scripts. If the devs do go that way it would still be handy to make it accessible externally.