<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/1/12 Juhani Rautiainen <span dir="ltr"><<a href="mailto:jrauti@iki.fi" target="_blank">jrauti@iki.fi</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Fri, Jan 11, 2013 at 5:13 PM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com" target="_blank">mtdean@thirdcontact.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 01/11/2013 12:18 AM, Juhani Rautiainen wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Has anyone with the problems tried to log slow queries? This should<br>
pinpoint where the time is spent. Instructions:<br>
<a href="http://dev.mysql.com/doc/refman/5.5/en/slow-query-log.html" target="_blank">http://dev.mysql.com/doc/<u></u>refman/5.5/en/slow-query-log.<u></u>html</a> . From there<br>
some EXPLAIN and SHOW PROFILE for those queries should give concrete<br>
information instead of speculation. I haven't analyzed mysql queries but<br>
from Oracle side I've got over lots of experience. Principles should be<br>
similar.<br>
</blockquote>
<br>
Slowness is almost definitely not a problem with the SQL--that EIT SQL hasn't changed for years. It's most likely just that the EIT scanning thread is writing data to and, therefore, locking tables that are required for the scheduler to run. So, the scheduler thread is waiting on the EIT writes to complete/yield so it can finish. I wouldn't expect high MySQL CPU use due to a locking/wait issue, though, so I don't know what's causing that. <br>
</div></blockquote><div><br></div><div>As I said, I'm not that experienced with MySQL, put at least with Oracle this happens time to time. There the problem is changing size of data. That changes query execution plans. Sometimes queries that used to take under second can take minutes or hours (very rare). Usually this is related to table/index statistics and usually the change happen literally over night. And checking MySQL docs there are similar heuristics here. How the statistics are gotten in MySQL seem to vary between MyISAM and InnoDB. That's why I was suggesting checking for slow queries. If there are any, we could compare execution plans between systems. I don't see how logging slow queries hurts anything. At least you could easily rule this problem out.<br>
<br></div></div></div></div></blockquote><div><br>I have now tried to have EIT completely off for the last 24H and it was
like giving my mythbox a new life. No lagging at all. I have now turned
on logging for slow mysql queries (longer than 20 seconds), and also turned on passive EIT
scanning.<br><br></div><div>And here we go again:<br></div><div><br>2013-01-14 20:36:10.697272 I [16203/16230] Scheduler scheduler.cpp:2129 (HandleReschedule) - Reschedule requested for MATCH 0 0 0 - EITScanner<br>2013-01-14 20:36:57.013252 I [16203/16230] Scheduler scheduler.cpp:2242 (HandleReschedule) - Scheduled 140 items in 46.2 = 45.42 match + 0.18 check + 0.60 place<br>
</div></div><br></div><div class="gmail_extra">mysqld is again at 100% CPU in this time window, but the query is not logged by mysql as a slow query for some reason?<br><br></div><div class="gmail_extra">I'm guessing that the passive EIT scan gives it less data and that is the reason why it uses apx 40 seconds, compared to the 80+ seconds with active EIT scan enabled.<br>
</div><div class="gmail_extra"><br>-- <br>Jarle Thorsen
</div></div>