A few thoughts:
* If you're not already using memcached with a big RAM allocation as an
in-memory cache, I strongly recommend it. This will reduce churn on the
'objectcache' table in MySQL for things like localization caches and the
parser cache (which may be churning a lot if you're seeing a large spike in
both visits and edits).
* Consider separating MySQL out to its own VM for easier management or to
split up memory usage. Watch for high i/o usage and make sure indexes are
in memory... Beware that MediaWiki expects MySQL to be on the local network
and makes lots of roundtrips -- make sure if you use a separate VM to
locate it in the same DC at least.
* Consider setting up a read-only slave database in another VM; depending
on your workload this may also help keep expensive lookups on the
secondary. It's also possible to route certain kinds of queries to a
particular database replica, which we use a lot on high-load Wikipedia
sites. This is a little tricky but not impossible.
On Tue, Feb 18, 2014 at 2:11 PM, David Gerard <dgerard(a)gmail.com> wrote:
is getting hammered again. It looks
like MySQL is the
busiest portion - seriously just doing a lot of work.
Our current arrangement is: one box for MySQL, Apache, Lucene (the
latter reindexing weekly); two Squids; a load balancer. These are all
virtual machines on Linode (who we like). Apache and Squid boxes are
Ubuntu 12.04 servers.
The *usual* thing when we get hammered is that Reddit discovers an
amusing tumbleweed article. The squids take care of this, of course.
But then something like the Bill Nye/Ken Ham debate happens, we score
pretty highly in Google for skeptical material and a wide variety of
articles gets hit and MySQL has to work for a living.
So, what's a good approach to scaling up MySQL on a VM? Add more
memory? Add more cores? (How's MySQL 5.5-ubuntu do for multicore?) We
can trivially add more Squids, and we haven't doubled up on Apache but
shirley that won't be entirely unfeasible.
MediaWiki-l mailing list