Interiot and pgk were hanging around on IRC complaining about toolserver lag, so I gave them both PROCESS access in MySQL. This allows them to see what queries are running at any given time. I'm hoping that they will terrorise anyone responsible for running inefficient lag-inducing read queries, and thereby improve the situation.
-- Tim Starling
Tim Starling schrieb:
Interiot and pgk were hanging around on IRC complaining about toolserver lag, so I gave them both PROCESS access in MySQL. This allows them to see what queries are running at any given time. I'm hoping that they will terrorise anyone responsible for running inefficient lag-inducing read queries, and thereby improve the situation.
some queries (complex catscans!) quite are long queries; and the author of a tool can nothing do against the popularity of its tool...
greets, marco
On 4/9/06, Marco Schuster CDL-Klever@gmx.net wrote:
Tim Starling schrieb:
Interiot and pgk were hanging around on IRC complaining about toolserver lag, so I gave them both PROCESS access in MySQL. This allows them to see what queries are running at any given time. I'm hoping that they will terrorise anyone responsible for running inefficient lag-inducing read queries, and thereby improve the situation.
some queries (complex catscans!) quite are long queries; and the author of a tool can nothing do against the popularity of its tool...
Eh, cache the results. ... and/or fix your queries. The mysql planner is braindead, reordering a slow query can sometimes result in a 100x speedup.
some queries (complex catscans!) quite are long queries; and the author of a tool can nothing do against the popularity of its tool...
Eh, cache the results. ... and/or fix your queries. The mysql planner is braindead, reordering a slow query can sometimes result in a 100x speedup.
Yes, CatScan generates slow queries sometimes. To fix the worst, I have a cronjob running every minute that will kill any query running more than five minutes. So, if you see anything by daniel_www running more than six minutes, please tell me - something is broken then.
The tool has lots of options, caching would be quite tricky. One of the slow things is collecting subcategories recursively... perhaps I could try to cache that.
@Greg: I'll get back to you about optimizing queries :)
Regards, Daniel
Also see http://tools.wikimedia.de/~interiot/cgi-bin/zedbot,blame
-Dave
On Mon, Apr 10, 2006 at 05:12:40AM +1000, Tim Starling wrote:
Interiot and pgk were hanging around on IRC complaining about toolserver lag, so I gave them both PROCESS access in MySQL. This allows them to see what queries are running at any given time. I'm hoping that they will terrorise anyone responsible for running inefficient lag-inducing read queries, and thereby improve the situation.
-- Tim Starling _______________________________________________ Toolserver-l mailing list Toolserver-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/toolserver-l
toolserver-l@lists.wikimedia.org