[00:06:55] I feel like I'm going crazy—isn't there a page on mediawiki wiki on using mwcli to set up multiple wikis? [00:07:09] *for CentralAuth [00:27:50] (eh never mind, shouldn't actually need multiple wikis for this) [01:02:10] Okay, I'm cursed or something today—why would 'composer phpunit -- extensions/CheckUser/tests/phpunit/CheckUserClientHintsCommonTraitTest.php' not work? In fact, why can't I seem to run the tests for any extensions when specifying just a path or filter? I end up getting errors regarding being unable to find basically any class ever. [01:02:57] See https://phabricator.wikimedia.org/P84811 [01:04:24] I'm sure this is probably because I recloned my core repo but I can't figure out what I'm missing [01:09:11] Is CheckUser loaded in LocalSettings? [01:09:27] I'm guessing it probably is if you installed it using docker... [01:10:33] it is, and it works fine [01:12:10] The path looks right for the file [01:13:39] it'll happen if I do the full extension, too (e.g., -- extensions/CentralAuth) [01:14:47] I guess CheckUserClientHintsCommonTraitTest isn't actually a test that can be run standalone [01:15:13] because the file only includes a trait, not a full class [01:16:15] ah perhaps I picked a bad example. See https://phabricator.wikimedia.org/P84812 [01:17:09] composer installed dev dependancies? [01:17:29] yup [01:21:30] oh waiiiit [01:22:43] no nevermind I'm still stuck [01:31:02] (It's actually just CentralAuth and CheckUser that are failing, while my other extensions and skins are fine. I just did those two and thought they were all failing.) [01:55:56] oh my gosh [01:56:02] I'm gonna cry [01:56:07] ... I needed to run update.php [16:31:36] I asked about this yesterday but didn't get a response, so I'll ask again. My DB load is about 60% taken up by this particular query from the block table: https://pastebin.com/4xH5gQmE Is there any particular reason why this could be? It's only happening on our main wiki, and not our file repository wiki. [16:32:08] What does explain say? [16:37:51] It comes up with this: https://pastebin.com/w2yTRp4d Strangely, my PMM service shows the explain as being from our file wiki, despite the fact that I've explicitly sorted the queries to only show ones being done on the main. The manual explain, however, does not. [16:38:19] We do use CentralAuth, so I'm wondering if that's related in some way. [17:07:18] Reedy: I don't suppose the above tells you anything? It does seem to be scanning a lot of rows (over 9000), but I don't know what could be responsible for that. [17:09:13] Do you have a lot of blocks? :P [17:09:58] What version of MW? [17:12:46] It looks like you've got the queries that exist in https://github.com/wikimedia/mediawiki/commit/b9ff1195b1fe7865a14079eee88db4d98a02f7d2 (which was backported to REL1_43) [17:15:21] We're on 1.43.0 right now (need to update the point release but have been holding off due to a traffic spike due to new material from the subject matter). A select count(*) shows ~9400 rows or so. [17:16:59] it's not actualy in REL1_43, it's a WIP for a backport... https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1139468 [17:22:43] Would the updated queries help in this case, do you think? [17:24:15] Not 100% sure, but it seems interesting in a related area [17:24:29] I was looking to see if any caching may have been introduced [17:25:10] Tim might be interested, depending [17:25:42] We do definitely have a lot of blocks. This is Bulbapedia we're talking about, so we've got literally 20 years of data. [17:25:57] I can even see some autoblocks from April 2005. [17:26:10] Not like wikimedia wikis have a small amount of blocks either, so you're hardly the outlier [17:26:48] True, I can't even imagine how many Wikipedia has. [18:35:59] Q123888