Last modified: 2010-05-15 15:59:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11533 - MessageCache absurdly slow with CACHE_NONE with wgReadOnly mode enabled
MessageCache absurdly slow with CACHE_NONE with wgReadOnly mode enabled
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.11.x
PC Linux
: Normal major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-02 11:33 UTC by Arnd
Modified: 2010-05-15 15:59 UTC (History)
5 users (show)

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


Attachments
Replace includes/BagOStuff.php with this one to fix (MediaWiki 1.13.0) (17.15 KB, patch)
2008-08-16 11:47 UTC, Evgeny Kapun
Details

Description Arnd 2007-10-02 11:33:03 UTC
After upgrading from version 1.9.3 page delivery is incredibly slow (about 40s for each page). I think this is because of a timeout while mediawiki waits for the answer from a memcache server which is neither present nor configured.

This happens after upgrading from 1.9.3 as well as after upgrading from 1.10.2. Version 1.10.2 is working.

I also posted this on the mailing list.

Configuration:

- Opensuse 10.2, kernel 2.6.18
- mysql  Ver 14.12 Distrib 5.0.26, for suse-linux-gnu (i686) using 
readline 5.1
- PHP 5.2.0 with Suhosin-Patch 0.9.6.1 (cli) (built: Jul 30 2007 15:36:02) 

Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
    with Suhosin v0.9.10, (C) Copyright 2006, by Hardened-PHP Project
- All tarfiles from mediawiki.org 

Snippet from the logfile:

Start request
GET /php/mediawiki-testing/index.php5/Hauptseite
Host: XXXXXX
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: wikidb_TEST_session=rFnqDOnk9nzgQQT8VTisQzD3_s7LcaQYzRpfsHR3frMVr52AKd3BAg9bxIqmUpi8; wikidb_TESTUserID=8iO9l82DarQdetA26Z6DZzuhV5Vt9xdWLY26P5jcxak.; wikidb_TESTUserName=sc6hRE5cFxTj3ed-oZ7jPKbpfETRx7QvGrh2tFcXyP4.
Cache-Control: max-age=0

Main cache: FakeMemCachedClient
Message cache: MediaWikiBagOStuff
Parser cache: MediaWikiBagOStuff
Unstubbing $wgParser on call of $wgParser->setHook from efSubpageList
Fully initialised
Unstubbing $wgContLang on call of $wgContLang->checkTitleEncoding from WebRequest::getGPCVal
Language::loadLocalisation(): got localisation for de from source
Language::loadLocalisation(): got localisation for en from source
Unstubbing $wgUser on call of $wgUser->isAllowed from Title::userCanRead
Unstubbing $wgLoadBalancer on call of $wgLoadBalancer->getConnection from wfGetDB
IP: XXX.XXX.XXX.XXX
Unstubbing $wgOut on call of $wgOut->setSquidMaxage from MediaWiki::performAction
Unstubbing $wgLang on call of $wgLang->getCode from User::getPageRenderingHash
Unstubbing $wgMessageCache on call of $wgMessageCache->loadAllMessages from User::getGroupName
MessageCache::load(): cache is empty
MessageCache::load(): loading all messages from DB
MemCached set error in MessageCache: restart memcached server!
OutputPage::checkLastModified: client did not send If-Modified-Since header
Article::tryFileCache(): not cacheable
Article::view using parser cache: yes
Trying parser cache wikidb_TESTING:pcache:idhash:1-0!1!0!!de!2!edit=0
Parser cache miss.
Saved in parser cache with key wikidb_TESTING:pcache:idhash:1-0!1!0!!de!2!edit=0 and timestamp 20071002105913
OutputPage::sendCacheControl: private caching; Tue, 02 Oct 2007 09:45:03 GMT **
20071002105913	23.028	/php/mediawiki-testing/index.php5/Hauptseite anon
Request ended normally
Comment 1 Brion Vibber 2007-10-02 11:48:00 UTC
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. :)
Comment 2 Arnd 2007-10-02 11:54:25 UTC
You are right, $wgReadOnly is set. And (as I just tested) setting it to "false" resolves the performance problem. 
Comment 3 Brion Vibber 2007-10-02 13:33:17 UTC
Ok, that's a tacklable problem I think. :)

Changed summary to the more specific issue.
Comment 4 Russell Yanofsky 2008-03-13 01:09:26 UTC
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.

Comment 5 Brion Vibber 2008-03-13 17:34:32 UTC
$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. :)
Comment 6 Evgeny Kapun 2008-08-16 11:47:14 UTC
Created attachment 5179 [details]
Replace includes/BagOStuff.php with this one to fix (MediaWiki 1.13.0)
Comment 7 Aaron Schulz 2008-09-12 22:45:34 UTC
(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
Comment 8 Daniel Kinzler 2008-09-15 20:11:23 UTC
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? 
Comment 9 Denilson Figueiredo de Sá 2008-09-15 20:25:39 UTC
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.
Comment 10 Aaron Schulz 2008-09-28 00:05:24 UTC
Can you please submit a diff patch, not the whole file? Thanks.
Comment 11 Brion Vibber 2008-10-30 01:14:58 UTC
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?)

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


Navigation
Links