On Wed, Oct 26, 2011 at 6:29 PM, Carl (CBM) <cbm.wikipedia(a)gmail.com> wrote: Just a little sidenote, you may be interested in ns_is_favorite. There is one entry per namespace per dbname where `ns_is_favorite = 1` which is also the one used by the wiki when creating/redirecting native links. - Krinkle

Marlen Caemmerer wrote: Maybe there's some job/tool which started at that time which loaded rosemary so much?

Hi, Am 29.10.2011, 13:25 Uhr, schrieb Magnus Manske <magnusmanske(a)googlemail.com>om>: for me the same. I didn't change anything, but most queries are much slower than before (I got the first mails from the query killer at around 4 pm UTC yesterday). Chris / apper

DaB. schrieb: Something has changed very recently. I had occasionally received a cron error of But since ~24 hours ago I got many of those. I don't know what may be wrong (the target server too slow to answer the RPC? a flood of jobs migrated to SGE?) but I'm a bit concerned that we have redundants servers to ensure the crons registering to SGE are run, yet the registration may fail with pretty much no reason. Maybe we should start launching locally if cronsub fails.

On Sat, Oct 29, 2011 at 2:18 PM, DaB. <WP(a)daniel.baur4.info> wrote: Unless there was an enormous influx of users in the last 12 hours or so, this is not really an explanation. If you look at the rather simple query, you'll see that it's not so much that my tool needs 71 minutes to run. The issue is rather that the database server takes 71 minutes for a query that shouldn't even take 71 seconds. The "work smarter, not harder" approach is neither helpful nor winning many sympathies. I am aware that the toolserver needs both hardware and admin attention. I was not complaining about a lack of either. I was merely commenting on a very recent change for the worse, which might have an unrelated cause (a disk filled up, some configuration changed), and might thus have an easy fix. Yelling at people who mention a new and acute issue is not the way forward. Magnus

One more DB performance report/question. I am seeing some UPDATE queries that only change one row but take much, much longer than they ought to. Is anyone else seeing this? For example, the following type of query is getting killed from time to time in the p_enwp10 database on sql-s1. The query killers says it ran for over 400 seconds before being killed. The update is on a primary key, and I don't see any way to optimize it. At the time this is running the database connection is inside a transaction (AutoCommit = 0) if that matters. UPDATE tmpcategories SET c_category = 'A-Class_Water_supply_and_sanitation_articles', c_ranking = '425', c_replacement = 'A-Class' WHERE c_project = 'Water_supply_and_sanitation' and c_rating= 'A-Class' and c_type = 'quality' - Carl mysql> show indexes from tmpcategories; +---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | +---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+ | tmpcategories | 0 | PRIMARY | 1 | c_project | A | 4055 | NULL | NULL | | BTREE | | | tmpcategories | 0 | PRIMARY | 2 | c_type | A | 8110 | NULL | NULL | | BTREE | | | tmpcategories | 0 | PRIMARY | 3 | c_rating | A | 40553 | NULL | NULL | | BTREE | | +---------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

On Wed, Nov 23, 2011 at 6:13 PM, Platonides <platonides(a)gmail.com> wrote: The WHERE clause completely specifies a primary key, so at most one row is affected. That's why it is surprising to me that it would take very long. - Carl