Page MenuHomePhabricator

Special:Nuke takes a long time to display
Open, Needs TriagePublic

Description

Recently [[en:Special:Nuke]] has been lagging loading the screen. I had several sockpuppets with a large number of pages that would not load the other day. Before filing this, I tested it on my alt account User:TBallioni and it took took 30 seconds to load for an account with no pages created.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 22 2018, 11:17 AM
Aklapper renamed this task from Special:Nuke lagging to Special:Nuke takes a long time to display.Jun 22 2018, 12:37 PM
Aklapper added a project: Performance Issue.
Vvjjkkii renamed this task from Special:Nuke takes a long time to display to zgaaaaaaaa.Jul 1 2018, 1:02 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
Krenair renamed this task from zgaaaaaaaa to Special:Nuke takes a long time to display.Jul 1 2018, 2:00 AM
Krenair raised the priority of this task from High to Needs Triage.
Krenair updated the task description. (Show Details)
Krenair added a subscriber: Aklapper.
Marostegui added a subscriber: Marostegui.EditedJul 22 2018, 5:50 AM

This is hard to reproduce without being an admin.
I couldn't find the particular URL reported at T200137 for Commons, but I found this, can you let me know if it is the same thing?:

https://commons.wikimedia.org/w/index.php?title=Special:Nuke&target=REDACTED

What I have seen so far on the logs for that particular URL:

SELECT  rc_namespace,rc_title,rc_timestamp  FROM `recentchanges`    WHERE ((rc_new = 1) OR (rc_log_type = 'upload' AND rc_log_action = 'upload')) AND ((rc_user = 'REDACTED'))  GROUP BY rc_namespace, rc_title, rc_timestamp ORDER BY rc_timestamp DESC LIMIT 500  ;

That query takes around 50 seconds to execute on Commons - (we have a query killer that kills queries that take longer than 60 seconds, to avoid pile ups on the server)

root@db1081.eqiad.wmnet[commonswiki]> explain SELECT  rc_namespace,rc_title,rc_timestamp  FROM `recentchanges`    WHERE ((rc_new = 1) OR (rc_log_type = 'upload' AND rc_log_action = 'upload')) AND ((rc_user = 'REDACTED'))  GROUP BY rc_namespace, rc_title, rc_timestamp ORDER BY rc_timestamp DESC LIMIT 500  ;
+------+-------------+---------------+-------+--------------------+--------------+---------+------+------+------------------------------+
| id   | select_type | table         | type  | possible_keys      | key          | key_len | ref  | rows | Extra                        |
+------+-------------+---------------+-------+--------------------+--------------+---------+------+------+------------------------------+
|    1 | SIMPLE      | recentchanges | index | new_name_timestamp | rc_timestamp | 16      | NULL |  500 | Using where; Using temporary |
+------+-------------+---------------+-------+--------------------+--------------+---------+------+------+------------------------------+
1 row in set (0.00 sec)

Looks like it is using the wrong index for the plan, at least for this query:

root@db1081.eqiad.wmnet[commonswiki]> SELECT  rc_namespace,rc_title,rc_timestamp  FROM `recentchanges`  WHERE ((rc_new = 1) OR (rc_log_type = 'upload' AND rc_log_action = 'upload')) AND ((rc_user = 'REDACTED'))  GROUP BY rc_namespace, rc_title, rc_timestamp ORDER BY rc_timestamp DESC LIMIT 500  ;
Empty set (38.29 sec)

If we now FORCE the index to use the other one suggested on the explain (new_name_timestamp )the query goes a lot faster:

root@db1081.eqiad.wmnet[commonswiki]> SELECT  rc_namespace,rc_title,rc_timestamp  FROM `recentchanges`  FORCE INDEX(new_name_timestamp)  WHERE ((rc_new = 1) OR (rc_log_type = 'upload' AND rc_log_action = 'upload')) AND ((rc_user = 'REDACTED'))  GROUP BY rc_namespace, rc_title, rc_timestamp ORDER BY rc_timestamp DESC LIMIT 500  ;
Empty set (7.15 sec)
JJMC89 added a subscriber: JJMC89.