Last modified: 2014-09-29 16:24:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T54979, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 52979 - ApiQueryAllUsers-related queries causing lag on Wikidata
ApiQueryAllUsers-related queries causing lag on Wikidata
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.22.0
All All
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-18 07:25 UTC by MZMcBride
Modified: 2014-09-29 16:24 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MZMcBride 2013-08-18 07:25:51 UTC
We just had an issue where hung queries from the Web API were causing massive lag on one of the Wikidata servers. Example query snippet:

---
SELECT /* ApiQueryAllUsers::execute */  ipb_deleted,COUNT(*) AS recentedits,user_name
---

Lag as reported by <https://www.wikidata.org/w/api.php?action=query&meta=siteinfo&siprop=dbrepllag&sishowalldb=> was high:

---
<?xml version="1.0"?>
<api>
  <query>
    <dbrepllag>
      <db host="db1058" lag="0" />
      <db host="db1005" lag="0" />
      <db host="db1026" lag="26432" />
      <db host="db1021" lag="0" />
    </dbrepllag>
  </query>
</api>
---

Server log entry about killing the queries: <https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=80744&oldid=80742&diffonly=1>.

As soon as the queries were killed, lag decreased.

ApiQueryAllUsers needs investigation.
Comment 1 Sam Reed (reedy) 2013-08-19 10:20:57 UTC
Do we actually know what the problem query string was? The COUNT(*) AS recentedits looks slightly suspicious

Depending on how bad this is, it might be worth disabling the module on wikidata for the time being.
Comment 2 Sean Pringle 2013-08-19 13:17:02 UTC
For now I have a pt-kill job running to snipe these queries on s5 slaves after 10 mins. Will gather some examples.
Comment 3 Bartosz Dziewoński 2013-08-19 14:58:12 UTC
https://gerrit.wikimedia.org/r/#/c/79761/
Comment 4 Sean Pringle 2013-08-22 08:59:42 UTC
No more queries sniped yet.

However, the example wikidata query in the comment 3 gerrit changeset showed MySQL changing execution plans between wikis due to quite different index cardinality values. ANALYZE TABLE helped there, so this might be a maintenance issue.
Comment 5 Brad Jorsch 2013-08-22 13:26:30 UTC
When did you do the ANALYZE TABLE? I was already seeing the sane results yesterday on wikidatawiki, using sql.php from terbium.
Comment 6 Sean Pringle 2013-08-23 01:27:10 UTC
ANALYZE ran ~1h before comment 4.

Were you connecting to the wikidatawiki master? Or one of the slaves?
Comment 7 Brad Jorsch 2013-08-23 13:37:09 UTC
Master, apparently, since I didn't specify the "slave" option to sql.php (in fact, I didn't know about that option until just now when I checked the code to find out what it did; I'll have to remember to use that in the future).
Comment 8 Andre Klapper 2014-03-18 02:00:56 UTC
The query itself is listed in https://gerrit.wikimedia.org/r/#/c/79761/ but that patch is abandoned.

Is there anything further to be done in this ticket?
Or is this WORKSFORME now?
Comment 9 Andre Klapper 2014-06-10 11:57:30 UTC
Is there anything further to be done in this ticket, as the patch is abandoned? Or is this WORKSFORME now?
Comment 10 Brad Jorsch 2014-09-29 16:24:40 UTC
Let's WORKSFORME this one and chalk it up to a bad query plan per comment 4. People can reopen if it's still a problem.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links