-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
tstarling@svn.wikimedia.org wrote:
Revision: 34358 Author: tstarling Date: 2008-05-07 06:43:58 +0000 (Wed, 07 May 2008)
This breaks the site. Overloads the central DB. Reverted.
- -- brion
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brion Vibber wrote:
tstarling@svn.wikimedia.org wrote:
Revision: 34358 Author: tstarling Date: 2008-05-07 06:43:58 +0000 (Wed, 07 May 2008)
This breaks the site. Overloads the central DB. Reverted.
Detail: the s3 master (carrying centralauth DB) was stuffed with these reqs:
SELECT /* Database::safeQuery */ gu_id, lu_dbname, gu_salt, gu_password,gu_auth_token,
[sorry, cut off as I didn't do a SHOW FULL PROCESSLIST]
We were getting reports of a lot of "too many connections" errors on various wikis, mostly from people who *were* logged in but *not* with a merged account. With a merged account, or anonymous, I didn't seem to be having any problems.
It looks like something was triggering a lot of extra lookups, which perhaps aren't getting properly cached.
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber brion@wikimedia.org wrote:
With a merged account, or anonymous, I didn't seem to be having any problems.
I was getting these errors on various wikis (en.wikisource, en.wikipedia, and wikimediafoundation) with a merged account.
On Thu, May 8, 2008 at 4:19 AM, Brion Vibber brion@wikimedia.org wrote:
Detail: the s3 master (carrying centralauth DB) was stuffed with these reqs:
SELECT /* Database::safeQuery */ gu_id, lu_dbname, gu_salt, gu_password,gu_auth_token,
[sorry, cut off as I didn't do a SHOW FULL PROCESSLIST]
We were getting reports of a lot of "too many connections" errors on various wikis, mostly from people who *were* logged in but *not* with a merged account. With a merged account, or anonymous, I didn't seem to be having any problems.
It looks like something was triggering a lot of extra lookups, which perhaps aren't getting properly cached.
I investigated this problem. Full details at [1].
Executive summary: resetState() is called from saveToCache if we don't have fresh data from the master (i.e. if $this->mFromMaster is not true). Unfortunately, if no row is found, that variable is not set to true, whereas it is if a row IS found. I've put a patch for this problem at the below link, which fixes it on my wiki. It's always the one-liners ;-)
[1] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/User:Werdna/CentralAut...
On Thu, May 8, 2008 at 11:00 PM, Andrew Garrett andrew@epstone.net wrote:
Executive summary: resetState() is called from saveToCache if we don't have fresh data from the master (i.e. if $this->mFromMaster is not true). Unfortunately, if no row is found, that variable is not set to true, whereas it is if a row IS found.
Forgot to mention: As saveToCache() also calls loadState() to get fresh data if it's stale, we end up with an infinite loop if browsing with an unmerged account. Quite unfun.
wikitech-l@lists.wikimedia.org