[mythtv-users] HowTo tune MySQL for schedule time and in general?

[David Engel]

On Mon, May 06, 2013 at 08:17:58AM -0700, Karl Newman wrote:
> On Mon, May 6, 2013 at 7:26 AM, David Engel <david at istwok.net> wrote:
> 
> > On Sun, May 05, 2013 at 12:44:31PM +0200, Thomas Börkel wrote:
> > > On 05.05.2013 05:27, David Engel wrote:
> > >
> > > > Something doesn't add up here.
> > > >
> > > > In your first timing, the majority of time (5.88s) was spent in the
> > > > place phase.  That phase shouldn't be affected that much by DB
> > > > changes.  To get a later run in the 0.2s range, the place phase would
> > > > have had to sped up a lot and I can't see that happening with just a
> > > > DB change.  It is the match and check phases that are DB sensitive.
> > >
> > > Only thing I can say is that the scheduler always took these long times
> > > before my changes and now it is always fast.
> > >
> > > > In addition, the scheduler normally only runs the match and check
> > > > phases on things that might have changed.  That means you can't
> > > > arbitrarily pick scheduler runs and compare them because they might
> > > > not have done the same amount of work.  You can compare runs initiated
> > > > with "mythutil --resched" because those cause the scheduler to re-run
> > > > everything.  You can also compare runs by making a do-nothing change
> > > > to a single recording rule because those cause the scheduler to only
> > > > re-run the parts for that rule.
> > >
> > > I compared the times by scheduling a new non-conflict recording and then
> > > deleting it again.
> >
> > That sounds like a reasonable test.  Still, that amount of improvement
> > sounds way too good to be true.  If it works, though, enjoy. :)
> >
> > David
> >
> 
> I've been following this thread (even though I don't have any tuners with
> multiplexes and probably never will). I read your description of how the
> scheduler works and it prompted me to think about another possible
> scheduler strategy. As I understand it now (and I'm probably wrong on at
> least some part so please correct me), the scheduler uses each physical
> tuners first as it's assigning programs to tuners, and then uses the
> virtual tuners in a second+ pass (if it needs to move a program?). The way
> I was envisioning, it would start with the priority-ordered list of
> programs, beginning with the highest priority. When scheduling a program
> onto a tuner with multiple virtual tuners, the scheduler would then run
> through the rest of the list (in priority order) and try to schedule other
> programs onto the virtual tuners for that multiplex. After the virtual
> tuners were full (or no more programs can record on that multiplex), then
> move to the next physical tuner with the next unscheduled program in the
> original program list. After this first pass, then run through the second
> (or more?) "moving" pass to shuffle programs if needed (I'm a little fuzzy
> about that part).
> 
> I'm sure there are some complexities that I'm glossing over or not aware
> of, but is this even possible?

In a properly configured system, that's how it already works.  The
problems arise when the user increases the number of virtual tuners
after having added other tuners.  The reason is the whole virtual
tuner implementation is a bit of a kluge, albeit, an effective one.
It was done that way to work around assumptions throughout the rest of
the code that a tuner can only record one thing at a time.  We'd like
to fix that and do away with virtual tuners altogether, but it takes
time and effort, which are usually in short supply.

BTW, the "increasing the number of virtual tuners" problem was greatly
mitigated in version 0.26.  You just need to make sure that every
physcial tuner has a unique "Schedule order" value.  

David
-- 
David Engel
david at istwok.net