Kazuho@Cybozu Labs

????????? XRumer 7.0.10 Elite? ??URL????????! ?????????????????????????????! XRumer?? CAPTCHA??????????????????!

???????? XRumer 7.0.10 ? ??URL??????????!!! ?????????????????????????????! XRumer?? CAPTCHA??????????????????!

There's a big issue with continually polling SHOW PROCESSLIST like that though - one of the main reasons that MySQL Query Analyzer doesn't use that approach - it locks a major mutex when generating the processlist, LOCK_thread_count.

This is used pretty widely internally (and is one of the major mutex issues for scalability at the SQL layer imho), just checking the sql directory of a 5.1.35 source tree:

Cerberus:sql mark$ grep -rn LOCK_thread_count ./* | wc -l
163

So anybody reading this - beware. Using it "constantly" in production is *highly* not recommended (at least by me).

It's great for sampling though. :)

Jet Profiler for MySQL uses SHOW PROCESSLIST polling too. I totally agree on the advantages of using a statistical approach. It will give you the top offending queries. I've seen a lot of DBAs fighting (unindexed) queries in the slow query log, resulting only in minor performance improvements. Later, it turns out that the main load is caused by well-formed queries that are issued 10 times too often or so. They will never show up in the slow query log.

Thank you for your comment. I didn't know that Maakit could use processlist as a source. I will try using it.

mk-query-digest from Maatkit does similar analysis, and it can use the processlist as a source of queries.

It's good to examine two types of queries: those consuming resources (a lot of execution time in aggregate), and those that will create a poor user experience (slow execution time, even if rarely executed).