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.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
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)
Comment Actions
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)
Comment Actions
I can't reproduce this - searching for users, whether they've created a large number of pages or not, returns results almost immediately.