<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 July 2017 at 03:19, T L <span dir="ltr"><<a href="mailto:tlunde@gmail.com" target="_blank">tlunde@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Oh, it does complete.<br>
<br>
When I first encountered this last year, I had multiple (of whatever<br>
it is) going on a little Live X and, after _days_ at 100% CPU, I gave<br>
up and just dropped the box.  Now, with one core of a Xeon 56xx<br>
processor, it takes many hours, but it does eventually complete.  The<br>
only problem is that it keeps the database busy enough or tables<br>
locked or something that it screws up all of the recordings that try<br>
to start within that long period of time.<br>
<br><div class="gmail-HOEnZb"><div class="gmail-h5">On Fri, Jul 28, 2017 at 9:21 AM, Stephen Worthington<br>
<<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br>
> On Fri, 28 Jul 2017 08:13:12 -0500, you wrote:<br>
><br>
>>Hi Stephen -<br>
>><br>
>>Thanks.  I'll look into getting a ticket created.  It'd be good to<br>
>>have some limitations on the query.  I can't be the only one with<br>
>>problematic recordings.<br>
>><br>
>>You were right about the database difference between the two:<br>
>><br>
>>mysqldump -uroot -p mythconverg recorded recordedseek recordedrating<br>
>>recordedprogram recordedmarkup recordedcredits --where="chanid=1024<br>
>>and starttime='2017-07-18 20:30:00'" --no-create-db --no-create-info<br>
>>>good.sql<br>
>><br>
>>mysqldump -uroot -p mythconverg recorded recordedseek recordedrating<br>
>>recordedprogram recordedmarkup recordedcredits --where="chanid=1024<br>
>>and starttime='2017-07-18 21:00:00'" --no-create-db --no-create-info<br>
>>>bad.sql<br>
>><br>
>>[root@testvm tlunde]# cat good.sql | wc -c<br>
>><br>
>>85183<br>
>><br>
>>[root@testvm tlunde]# cat bad.sql | wc -c<br>
>><br>
>>20300732<br>
>><br>
>>Look at the size difference!<br>
>><br>
>>Thanks<br>
>>Thomas<br>
><br>
> Ouch!  That is a huge difference.  But even with that, the query<br>
> should complete eventually, unless something is thrashing, so the<br>
> query is probably too big to be executed in the available RAM.<br></div></div></blockquote><div> </div></div></div><div class="gmail_extra">Might also be worth running an EXPLAIN on the queries. Run the queries as before, but put the word "EXPLAIN" before the SELECT command, so it starts with "EXPLAIN SELECT ...".</div><div class="gmail_extra"><br></div><div class="gmail_extra">This will show how mysql will execute the query, but doesn't actually run it, so execution should be quick, even for the problem query.<br><div><br></div><div>Run this for both query versions, and see if there is any difference between the 2.</div><div><br></div><div>This will highlight things like order of joins of tables, which indexes are used etc.</div></div></div>