Main cache: FakeMemCachedClient
Message cache: MediaWikiBagOStuff
Parser cache: MediaWikiBagOStuff

That's using the local objectcache table for message cache storage.

The delay is from MessageCache::load() trying to ensure that it can properly save its data to the cache storage. It'll loop as long as the set() calls fail.

A quick peek at the code for SqlBagOStuff in includes/BagOStuff.php indicates that this should return a failure result only if the wiki is set in read-only mode; otherwise it always returns success, or else the entire system dies if there's a database error.

Can you confirm whether $wgReadOnly is set? That oughtn't to blow up the wiki like this, but if that's it that saves us some trouble tracking it down. :)

amuenzeb wrote:

You are right, $wgReadOnly is set. And (as I just tested) setting it to "false" resolves the performance problem.

Ok, that's a tacklable problem I think. :)

Changed summary to the more specific issue.

rey4 wrote:

I got bitten by this bug during an upgrade from MediaWiki 1.8.4 to 1.11.2. With the wgReadOnly flag turned on, the update script crawled along for hours (during the deleteDefaultMessages step) barely making any progress updating the database. After disabling wgReadOnly, the upgrade finished in less than a minute. It would be really great if this were fixed. The problem is just that the SqlBagOStuff::set method always returns false when wgReadOnly is enabled. This causes the MessageCache::load method to hang (for up to 30 seconds each time it is called), because it calls SqlBagOStuff::set in a loop, waiting for it not to return false.

$wgReadOnly is supposed to prevent any database writes, so that would prevent an updater script from working in the first place... unless it's broken horribly. :)

Replace includes/BagOStuff.php with this one to fix (MediaWiki 1.13.0)

Attached:

(In reply to comment #6)

Created an attachment (id=5179) [details]
Replace includes/BagOStuff.php with this one to fix (MediaWiki 1.13.0)

Please submit a diff

Please get this fixed, it's annoying :)

Oh, and... shouldn't update.php work in readonly mode? wouldn't it be nasty to have people editing while it's running?

denilsonsa wrote:

I had 1.11.1, then I enabled $wgReadOnly (because I was about to update my wiki).
Then I replaced the mediawiki files to 1.13.1 (preserving AdminSettings.php and LocalSettings.php).
Then I ran update.php from command-line. (which ignores $wgReadOnly)
Then I tried to access the wiki... and things were painfully slow. I mean, 1 minute or more to load any page.

Then I disabled $wgReadOnly, and everything was blazing fast again.

Can you please submit a diff patch, not the whole file? Thanks.

Fixed in r42796. Depressingly, this was a one-line fix. :)

Since read-only mode these days no longer actually enforces the "can't write anything to the DB" rule, just having read-only mode *not* disable cache writes fixes it nicely. Today's read-only mode is meant merely to prevent user-visible actions. (This of course means that it's insufficient for running on a database that's *actually* read-only, as some activity that causes background writes, such as the objectcache, would fail. But since we're already in that state, let's let things work in the common case, eh?)