The problem: In general, rationalwiki.org is melting under the strain.
We can't quite afford the next step up right this moment, though want
to plan for it, and need to keep things from intermittently blowing up
as they are.
We live on a 4GB Linode. I don't have a full handle on what we've got
on it - it's accreted in an ad-hoc fashion with some horrible bodges -
but there's several MediaWikis, only one of which (rationalwiki.org)
has any appreciable traffic. There's Lucene search, which is of course
huge in memory. rationalwiki.org is running via libphp5, the other
wikis are via fastcgi (for no particular reason). The wikis have a
huge pile of extensions, e.g.
http://rationalwiki.org/wiki/Special:Version , a lot of which are
local things.
Whenever an article hits Reddit,[1] the server suffers under the load.
Typically it goes into swap and thrashes itself to death. If we're
really lucky the oom-killer comes out to play and shoots things
randomly (usually Apache, maybe Lucene). The fun bit: sometimes it
does this for no visible reason, just tips over into swap and promptly
stops talking to the world (my shell session still works slowly).
Per advice from here I've re-enabled keepalive, setting it to 10
requests and 2 seconds. This does speed things up a bit for the users.
I haven't put a cache on the front as yet, still letting MediaWiki's
file cache do that. apc is running (99.8% cache hit rate, so that's
fine) and memcached (90% cache hit rate, upped it from 64MB to 128MB
and it's still about 90%).
So second thing we need to work out what our next stage of evolution
is (the 8GB Linode for $200/mo more? [2] or multiple servers?
Distributed how?) - and the first thing we need to work out how not to
make the box melt in the meantime.
Clues welcomed!
- d.
[1] usually a joke article, like
http://rationalwiki.org/wiki/Scientific_evidence_of_evolution_being_a_hoax
... nothing we've actually worked hard on *hand to forehead*
[2] this appears pretty typical pricing for non-crappy hosting
I'm trying to get MediaWiki going with Oracle as the backend. It is listed
as ready for beta test in the 1.17 release notes.
"Oracle Database support has been improved, and is now ready for beta
testing...Oracle support is not yet recommended for use in production."
I haven't seen any mention of Oracle since 1.17.
I've hit several showstopper bugs in the installer which makes me wonder if
Oracle support is still being worked on. I realize it's beta, but these
are "you can't get past the installer using Oracle" types of things. Examples
are bugs 41063 and 41146 which I filed this week. .
I'm not asking about those bugs per se, but rather an overall question - is
Oracle support still being actively developed or has it fallen to the
wayside? If it's no longer really being worked on, cool, I'll switch
gears...if it is, then I'll wait on the bugs.
Hopefully this doesn't come off as whinging - just asking overall about
Oracle support for MW.
Thanks!
To whom it may concern,
I was in the IRC channel and sumanah had recommended that I inquire about my issue via the mailing list, so here goes. I am trying to set up SMTP use for my MediaWiki Server. I am running Windows Server 2008. I have installed all of the Pear Mail modules to get this running, however when I enter the variables for $wgSMTP I am getting several lines of errors.
SMTP is running on my local machine and does not require any form of authentication:
$wgEmailEmail = true;
$wgEnableUserEmail = true;
$wgSMTP = array(
'host' => "localhost", //could also be an IP address
'IDHost' => "wiki.notify.net",
'port' => 25,
'auth' => false
);
However, when I create a new account, attempt to send the e-mail for a password reset, I am getting the following errors:
Strict Standards: Non-static method Mail::factory() should not be called statically in C:\xampp\htdocs\wiki\includes\UserMailer.php on line 245
Strict Standards: Non-static method PEAR::isError() should not be called statically in C:\xampp\htdocs\wiki\includes\UserMailer.php on line 246
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Mail\smtp.php on line 365
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 450
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 467
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 474
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 517
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 265
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 521
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Mail\smtp.php on line 249
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Mail\smtp.php on line 285
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 952
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 265
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 955
Strict Standards: Non-static method Mail_RFC822::parseAddressList() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Mail.php on line 253
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 982
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 265
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 985
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 1063
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 265
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 1066
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 1126
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 265
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 1136
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 265
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 1141
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 491
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 265
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 494
Strict Standards: Non-static method PEAR::isError() should not be called statically, assuming $this from incompatible context in C:\xampp\php\pear\Net\SMTP.php on line 497
Strict Standards: Non-static method PEAR::isError() should not be called statically in C:\xampp\htdocs\wiki\includes\UserMailer.php on line 101
Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\php\pear\Net\SMTP.php:265) in C:\xampp\htdocs\wiki\includes\WebResponse.php on line 78
Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\php\pear\Net\SMTP.php:265) in C:\xampp\htdocs\wiki\includes\WebResponse.php on line 78
Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\php\pear\Net\SMTP.php:265) in C:\xampp\htdocs\wiki\includes\WebResponse.php on line 78
Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\php\pear\Net\SMTP.php:265) in C:\xampp\htdocs\wiki\includes\WebResponse.php on line 38
Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\php\pear\Net\SMTP.php:265) in C:\xampp\htdocs\wiki\includes\WebResponse.php on line 38
Warning: Cannot modify header information - headers already sent by (output started at C:\xampp\php\pear\Net\SMTP.php:265) in C:\xampp\htdocs\wiki\includes\WebResponse.php on line 38
Thank You,
Douglas E. Mills
IT Administrator
Notify Technology Corporation
330-702-3070 x189
dmills(a)notifycorp.com<mailto:dmills@notifycorp.com>
> From: David Gerard <dgerard(a)gmail.com>
>
>> The MW file cache might be fast, but Squid is always going to be faster.
>
> We're quite fond of our "This article has been viewed x times" at the
> bottom of the pages, though I'm quite aware that's an expensive
> affectation that we may well have outgrown.
I think it's just a simple database query. At least I have a "mw_hitcounter" MEMORY table in my database. But maybe it's leftover cruft from past upgrades...
----------------
:::: Some of the current attempts at energy accounting, like the triple bottom line, are an absolute a joke. They're an insult to children even in terms of their intellectual content, because they try and compare vague abstractions of social and environmental values -- just dot pointed -- against a completely econometric financial accounting system of an organization which is actually doing the work. -- David Holmgren
:::: Jan Steinman, EcoReality Co-op ::::
I am out of the office until 10/22/2012.
Currently in JNCIE-ENT training.
For any issues regarding Classroom Connect, please call the Metrotech desk
at 718-935-5424 and/or email nycboew(a)us.ibm.com
Note: This is an automated response to your message "MediaWiki-l Digest,
Vol 109, Issue 20" sent on 10/15/2012 8:00:14.
This is the only notification you will receive while this person is away.
Hello,
Just to let you know that I think that the extension distributor is not working.
I'm trying to download the Validator extension for an 1.19.x Mediawiki release and after selecting the MediaWiki version I have this error message : nvalid response from Extension Distributor remote client.
Thanks to notify me when the problem is fixed!
Regards,
Nathalie
AVIS : Ce courrier et ses pieces jointes sont destines a leur seul destinataire et peuvent contenir des informations confidentielles appartenant a bioMerieux. Si vous n'etes pas destinataire, vous etes informe que toute lecture, divulgation, ou reproduction de ce message et des pieces jointes est strictement interdite. Si vous avez recu ce message par erreur merci d'en prevenir l'expediteur et de le detruire, ainsi que ses pieces jointes.
NOTICE: This message and attachments are intended only for the use of their addressee and may contain confidential information belonging to bioMerieux. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, or copying of this message, or any attachment, is strictly prohibited. If you have received this message in error, please notify the original sender immediately and delete this message, along with any attachments.
(I have just accepted root on rationalwiki.org and am looking around
in slight horror. I will be sending a few messages like this.)
Apache comes with KeepAlive on by default. I am unconvinced this is
actually a good idea. I just switched it off and it appears to have no
ill effects, and the server has 400MB more free memory. (Ubuntu 10.04
Linode with 4GB RAM. Six wikis, Lucene search being really fat.)
The only mention I can see on mediawiki.org is in
http://www.mediawiki.org/wiki/Manual:Newcomers_guide_to_installing_on_Windo…
, where it's one of the defaults they say nothing about.
Apache connections are really pretty damn cheap these days. Is
KeepAlive actually a good or bad thing for MediaWiki?
- d.
I'm getting reports on rationalwiki.org of occasional blank
watchlists. The symptoms are that a completely empty page loads
immediately. It's running 1.19.1 in Ubuntu 10.04 with Apache
2.2.14-ubuntu.
Of course, I changed *two* things last night: (a) cut max memory for
PHP from 256MB to 64MB (b) switched off KeepAlive in Apache. (I'm
quite keen to keep both of these, as the server CPU and memory went
*right* down.)
The confusing thing is the Apache logs don't show any "200 0" for
Special:Watchlist, at all. So either it's serving something that
renders as a blank page, or something before Apache, which should be
nothing whatsoever, is showing a blank page. I see a few "200 0" for
other pages. A bit over 1% of all connections give a 408 request
timeout - but the request timeout is 300 seconds, which is quite huge
enough.
I've asked people having the problem to email me with their IP and the
time, so I can go log-grovelling. But has anyone else seen this, and
what caused it?
- d.