<div dir="ltr"><div>It's a big ol' honking tool all right, which is why I made [1], which is /much/ faster. However, some complex queries from catscan2, especially when used in combination, are rather hard to do is a single query, and holding everything in PHP memory is probably less efficient than temporary MySQL tables.<br>

<br></div>One issue is that I can't really predict at runtime which query will take 5 seconds and which will take 12 hours. I'd be happy to set a generic limit on the tool, but I don't know how to do that for the MySQL query.<br>

<div><div><div><br><br>[1] <a href="http://tools.wmflabs.org/catscan2/quick_intersection.php">http://tools.wmflabs.org/catscan2/quick_intersection.php</a><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Tue, Dec 10, 2013 at 2:14 PM, Tim Landscheidt <span dir="ltr"><<a href="mailto:tim@tim-landscheidt.de" target="_blank">tim@tim-landscheidt.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">Marc-André Pelletier <<a href="mailto:mpelletier@wikimedia.org">mpelletier@wikimedia.org</a>> wrote:<br>
<br>
>> The same thing happened yesterday; Coren determined that a certain project<br>
>> that shall remain nameless, unless you consider "catscan2" to be a name, had<br>
>> been holding a lock on the database for over 12 hours.<br>
<br>
> And indeed that's the case again; I need to sit down with the catscan<br>
> people and find a better way for them to do whatever it is they are<br>
> trying to do in a way that does not result in:<br>
<br>
> ---TRANSACTION 9337D917, ACTIVE 52358 sec fetching rows<br>
> mysql tables in use 3, locked 3<br>
> 566321 lock struct(s), heap size 56850872, 10281493 row lock(s), undo<br>
> log entries 150718<br>
<br>
> I really want to avoid having to install a query killer and place hard<br>
> time limit on running time - no matter where the line it it will be an<br>
> annoyance to /someone/.  There are occasional legitimate uses for very<br>
> long queries; but they should be infrequent and not last *that* long.<br>
<br>
</div>IIRC it's not necessarily long queries that lock down the<br>
DB, but queries that requests locks :-).  I see temporary<br>
tables and inserts in the catscan2 code, and I think that<br>
might be the culprit.<br>
<br>
That was one of the many surprises when moving from<br>
Toolserver to Labs: On Toolserver, a tool could request a<br>
lock for a minute (or whatever the threshold for the query<br>
killer was), the replication lag would go up, but the query<br>
that actually got killed was the read-only one that had been<br>
running peacefully for hours and not increased replication<br>
lag in any way.<br>
<br>
So, *please*, if we think about enabling some sort of query<br>
killer on Tools, let's make *very* sure that it aims accu-<br>
rately.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Labs-l mailing list<br>
<a href="mailto:Labs-l@lists.wikimedia.org">Labs-l@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/labs-l" target="_blank">https://lists.wikimedia.org/mailman/listinfo/labs-l</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">undefined</div>
</div>