[mythtv-users] Slow MySQL query after delete

Larry K lunchtimelarry at gmail.com
Sun Dec 2 17:11:40 UTC 2007


When I read you post about the icons, I thought maybe that could be a
factor.  I say that because my channels table had nothing in the icon
column, but as it turns out, having nothing is not a problem if you don't
care about seeing the icons.  I guess when I switched from zap2it to
SchedulesDirect, I lost the icons and never really noticed.  I populated the
icons (per the wiki) and now I have them, but nothing has changed otherwise.

Since you believe this has nothing to do with the slow scheduler query, and
since enabling slow deletes made no difference. and since yours works
without the use of InnoDB, can you offer any other suggestions as what this
could be?  Issues to investigate?  Configuration changes to consider?
Verbose logging that might shed light on it?  Anything?

On 12/1/07, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>
> On 12/01/2007 04:03 AM, f-myth-users at media.mit.edu wrote:
> >     > Date: Sat, 01 Dec 2007 00:17:43 -0500
> >     > From: "Michael T. Dean" <mtdean at thirdcontact.com>
> >
> >     > On 11/30/2007 05:12 AM, f-myth-users at media.mit.edu wrote:
> >     > > It is also completely unreasonable for you to ignore and dismiss
> all
> >     > > the evidence people are handing you that RESCHEDULES ARE SLOW
> even
> >     > > if one has ARLEADY DONE all of the recommended screwing around.
> >
> >     > How many times do I have to say, "His system takes the same amount
> of
> >     > time for a scheduling run as my system and my system does /not/
> lock
> >     > up--or show /any/ delay at all--after a delete," before it's
> apparent
> >     > that my system can somehow run a "SLOW" reschedule without
> affecting UI
> >     > responsiveness?  Am I the only one to whom this implies that the
> "SLOW"
> >     > reschedule is /not/ the issue?
> >
> > There are two points here.  One is that reschedules are slow no matter
> > what you're doing,
>
> Fine.  Look.  I'm not saying that it can't be improved--there's not a
> single place in Myth that can't be improved, as nothing is ever
> perfect.  I'm simply saying that the "recent OP"--the guy who has a
> problem and restarted this thread--can make his system perform much
> better.  It seems there are far too many people trying to convince him
> that there's nothing he can do because Myth is broken and the scheduler
> was improperly designed.
>
> Daniel and Janne have actually made some changes that make the
> scheduling faster (maybe only committed to multirec so far, though--I
> don't remember).  Chris Pinkham promised you that he would make (and he
> has already made some) changes which make the DB locking less of an
> issue.  Others may have also made some changes.
>
> Though I can't guarantee it--because I'm a non-dev and because I don't
> make decisions (so arguing with me is really a waste of both our time),
> I'm pretty certain no major rewrite of the scheduler will be done in
> 0.20-fixes (stable) branch.  I'm even more certain that no major rewrite
> of the scheduler will be done in the 0.18-fixes (archive) branch.
>
> >  for some users.
> >
>
> And /there/ is the important point.  Find out why it's only /some/ users
> and--if, in fact, the configuration difference is a Myth bug, I will fix
> it for you.
>
> > Now, as for your own performance, can you please run a couple of tests
> > and let us know how -your- system performs?
>
> That will have to wait until I can find the time.
>
> > If you cannot ever get the UI to pause while doing this, I'm sure many
> > of us would be interested to know the size of your oldrecorded tables
> >
>
> 7072 in oldrecorded, 2903907 in recordedseek, 4577 in recordedmarkup
>
> > and the number and makeup of your recording rules,
>
> 78 in record (all are currently always/any channel rules--though I often
> add up to 20 find once/any channel rules for movies), 413 in
> recordmatch, 437 in recorded.
>
> Every table in the DB is MyISAM with the exception of the new
> MythWeather tables, which are InnoDB (see
> http://www.gossamer-threads.com/lists/mythtv/dev/302941#302941 ).
>
> Oh, and, I've deleted at least 10 shows today, so those numbers were
> higher.
>
> >  as mentioned in
> > that old thread about scheduler performance from a few months ago.
> > Also interesting would be the match/place lines from your sched logs,
> > and the contents of your MySQL conf (e.g., memory allocations, etc).
> >
>
> It's the default one that's installed from a source install--with the
> one exception that I disabled (commented) log-bin.
>
> >     > Never optimize before profiling.  IMHO, picking something--no
> matter how
> >     > "likely" to be the problem--and changing it without actually
> proving it
> >     > is the source of the problem is just a waste of time.
> >
> > You seem to be completely ignoring the fact that you've been told
> > repeatedly that simple reschedule -is- a big problem,
>
> I've been told a lot of things.  I believe very little of of what I'm
> told until I have proof.
>
> > P.S.  One way of verifying your contention that it's the actual
> > removal of the recordedseek info that's causing deletions to
> > be slow
>
> I _never_ said that removal of recordedseek info causes deletion to be
> slow.  As a matter of fact, I have never even agreed that deletion is
> slow--as it isn't for me.
>
> I simply made a comment which tried to point out that--despite what many
> had said in the thread--enabling slow deletes on a fast filesystem
> /does/ have an effect.  I did not say that effect would fix the
> slowness.  I did not say that removing records from recordedseek is slow.
>
> Far too many people seem to be forgetting that there's a /lot/ going on
> in the system and that few people have a clear picture of all that
> happens.  I know enough about what happens to know that I don't have a
> clear picture of all that happens.  Because of this, even things that
> don't seem to be relevant may actually be relevant.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20071202/3a936be5/attachment.htm 


More information about the mythtv-users mailing list