Some thoughts:
* Use a front-end web cache.
The old 'file cache' in MediaWiki probably doesn't work as well as it once
did, especially since you're on a recent version of MediaWiki that uses
ResourceLoader -- that'll mean dynamic hits happen for styles and scripts
even on a cached page -- and even that cached page is going through
MediaWiki and requires CPU time and memory.
I'm not sure whether any of the cloud-based CDNs play nicely with MediaWiki
these days, but you can certainly set up Squid or Varnish on a second
Linode box.
A proper caching setup that covers both article views and ResourceLoader
(load.php stuff) should be able to avoid a *lot* of hits to PHP as long as
people are just clicking around.
You can also do things like loading static resources (uploaded files, skin
images etc) from a separate server, but putting a cache in front should
cover much the same requirements as that.
* Consider splitting Lucene search to a separate server.
Particularly since it's memory intensive, splitting it out will leave more
RAM on your main server for handling spikes.
* Do some load tests and set maximums appropriately
If you've got a lot of MediaWiki hits going simultaneously, that's going to
drive up your memory usage. Make sure that hitting the maximum number of
server threads doesn't kill you just from loading up Apache+PHP+MediaWiki!
-- brion
On Wed, Oct 17, 2012 at 3:25 PM, David Gerard <dgerard(a)gmail.com> wrote:
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
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l