Hello folks:
We host our support site (www.longjumpsupport.com) from LunarPages. The site is terribly slow today, either not loading pages (stalling) or timing out. We upgraded to V1.13 (from 1.12) at the beginning of October, and it has been working very well until this morning.
I contacted the LunarPages folks, and after asking me what the application requirements were for MediaWiki (!), they said that the reason is that the * index.php* file was working too hard/running too many scripts, and causing the timeouts.
The tech said he would make notes regarding the problem and send them to me, however I don't know what this data indicates or how to resolve the problem.
Has anyone encountered this before, or have suggestions?
TIA, Evelyn
---- TECH RESPONSE STARTS HERE ----
Hello, Per your request the load on your user is as follows:
CPU usage 2.96 MEM usage 0.62 MySQL usage 1.0 Top Process%CPU 41.0[php-cgi] Top Process%CPU 39.0 /usr/local/php5/bin/php-cgi /home/.../wiki/index.php Top Process%CPU 36.0 /usr/local/php5/bin/php-cgi /home/.../wiki/index.php Best Regards, ...
---- TECH RESPONSE ENDS HERE ----
fyi, I figured it out.... I wanted to lock the database from changes, and used this command in localsettings.php
$wgReadOnly = 'site maintenance';
Unexpectedly, this is the reason for the problem. Nothing in the MediaWiki documentation warns that the database will be unusable. I expected that users could continue to use the site in read-only mode. If anyone has a reason for this, I'd be interested to hear your explanation. To solve the issue, I revoked user editing rights to lock it down. All is well now. Thanks,
- Evelyn ~~~~~~~~~~~~~~ Evelyn Yoder www.longjumpsupport.com
On Wed, Oct 29, 2008 at 2:55 PM, Evelyn Yoder eyoder@gmail.com wrote:
fyi, I figured it out.... I wanted to lock the database from changes, and used this command in localsettings.php
$wgReadOnly = 'site maintenance';
Unexpectedly, this is the reason for the problem. Nothing in the MediaWiki documentation warns that the database will be unusable. I expected that users could continue to use the site in read-only mode. If anyone has a reason for this, I'd be interested to hear your explanation. To solve the issue, I revoked user editing rights to lock it down. All is well now. Thanks,
- Evelyn
Evelyn Yoder www.longjumpsupport.com
Bug 11533: https://bugzilla.wikimedia.org/show_bug.cgi?id=11533
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Benjamin Lees wrote:
On Wed, Oct 29, 2008 at 2:55 PM, Evelyn Yoder wrote:
fyi, I figured it out.... I wanted to lock the database from changes, and used this command in localsettings.php
$wgReadOnly = 'site maintenance';
Unexpectedly, this is the reason for the problem. Nothing in the MediaWiki documentation warns that the database will be unusable. I expected that users could continue to use the site in read-only mode. If anyone has a reason for this, I'd be interested to hear your explanation. To solve the issue, I revoked user editing rights to lock it down. All is well now.
Bug 11533: https://bugzilla.wikimedia.org/show_bug.cgi?id=11533
Bah! That was a depressing one-line fix that never got applied. :)
Applied now to trunk: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/42796
To fix this on your local copy quickly: * open includes/BagOStuff.php * find the wfReadOnly() call * replace it with "false", changing this:
function _readonly(){ return wfReadOnly(); }
to this:
function _readonly(){ return false; }
- -- brion
Brion Vibber wrote:
Benjamin Lees wrote:
Bug 11533: https://bugzilla.wikimedia.org/show_bug.cgi?id=11533
Bah! That was a depressing one-line fix that never got applied. :)
Applied now to trunk: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/42796
Read-only mode has been repurposed from the original "nothing must write to the database" to "users should not be able to edit or alter anything user-visible".
wfReadOnly() wasn't preventing db writes by the article counter and some other stuff so preventing objectcache writes was a bit inconsistent.
mediawiki-l@lists.wikimedia.org