Projects Tech Stuff

MySQL Optimization for WordPress

We’ve been running one WordPress multisite installation here at work for about three years, and over the summer launched a second. But this one is a whole other kettle of fish, as Dr. Winzenburger used to say.

Rolling out an installation with 1600 blogs — one for each student plus a number of mentors and faculty members — and then running mass training sessions for them — leads us into some pretty rough waters. Almost immediately after the classes started, people were getting “Could Not Connect To The Database” screens.

Is it any surprise that the out-of-the-box MySQL options are inadequate for this kind of traffic? Pretty embarrassing, and time for a true fire drill.

First we added an extra process to the virtual box, and doubled the memory. No dice. We made a few tweaks to Apache. Nothing. My revolutionary flash of insight was, if we’re seeing “can’t connect to database,” maybe there’s something wrong with the database.

So started to play with the settings. You can do each of these by running a query, either in a database app like phpmyadmin or Navicat, or from the command line on the box itself. A query might look like this:

SET GLOBAL query_cache_size=64000000;
SET GLOBAL max_connections=1000;

That lets you see right away if there’s an effect, but the changes are lost next time the system restarts. To change these permanently, look for your my.cnf file. Maybe it’s in /etc? Depends on your flavor of Linux. Then BEFORE the second that looks like this:


For our bigger installation with ~15,000 tables we added this:


Nothing like that exists, so don’t worry. These are overriding the defaults.

Similar...  New PC Diary, Part 1

For the smaller, with ~3,000 tables, this:


Not much of a difference.

Then find the directory that has mysqld (maybe /something/something/init.d, again depending on your flavor) run ./mysqld restart. All should be well.

One thing we ran into before goosing up our tmp_table_size enough was that a table_cache of 512 had the odd side-effect of making all of our databases disappear. That wouldn’t be good. I was relieved to find that lowering it back below whatever phantom threshold there was made them re-appear again (is that an understatement?) Once I increased the other values, it was possible to run the number up higher.

Just for comparison’s sake, the default values are:

*caching is turned off altogether by default!

If you have phpmyadmin running, the Runtime Information screen highlights in red some of the settings to watch out for, along with hints on what to change.

These were the “final” settings; at the close of business the day earlier we’d put in somewhat lower numbers — table_cache was 256, key buffer size was 64M — and it worked without a hitch. The next day is going to be extra busy, so hopefully these will give us even more headroom.

Leave a Reply

Your email address will not be published. Required fields are marked *