[mythtv-users] Slow MySQL query after delete

Michael T. Dean mtdean at thirdcontact.com
Sun Dec 2 00:04:43 UTC 2007


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


More information about the mythtv-users mailing list