I host several Wordpress sites on my Linode VPS, some of which are quite active and others that are for development purposes or just generally quiet. The VPS itself runs Debian Lenny and the sites are served by Apache, reverse proxied from Nginx. It’s a little bit over-complicated but the set-up is sweet, fast and until a few months ago, really stable.
However, sometime at the start of the year, Apache would sometimes throw a wobbler during the night here in the UK. Perhaps one day in 14 I’d get up and find my VPS slowed to a crawl; the culprit would be Apache hogging the CPU. Ouch! Restarting the Apache process would calm things down and I didn’t need to reboot but obviously something was awry.
At first I thought that the problem was an Apache misconfiguration. I focused my attention on a few segments of the main Apache configuration file and fiddled with these as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | <ifmodule mpm_prefork_module> StartServers 3 MinSpareServers 3 MaxSpareServers 7 MaxClients 20 MaxRequestsPerChild 1000 </ifmodule> <ifmodule mpm_worker_module> StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 </ifmodule> |
This didn’t do the trick (although the configuration is sound). I decided to trawl through my log-files and found that since most of my visitors are UK based, the sites were generally quiet during the UK night. However, around 6.00am, I’d get hit with a plethora of robots from all over the place wanting to spider my site. So that’s a good thing yeah? Well not in my case. It was around this time that my VPS would go wonky.
I wondered about the Wordpress pseudo-cron facility. Wordpress can perform tasks on your site(s) at pre-determined times but in the absence of a real cron, the task is triggered on the next page load after the scheduled time has passed.
I run several time dependent plug-ins on my sites such as Lifestreams, RSS feeds and Caches, so if these weren’t going to run until a page load, and there were next to no page loads in the night, then when the robots came-a-calling, all the cron jobs across several sites would trigger at the same time. So I thought about a solution and came up with:
- Disabling the Wordpress pseudo-cron
- Enabling a remote cron where I could control the time schedule
Disabling the Pseudo-Cron
This is easy. All you need to do is add this code-snippet into your wp-config.php file:
1 | define('DISABLE_WP_CRON', true); |
Once added, that’s it. Wordpress doesn’t run its cron on page loads. OK, so now we need to run a real cron. I run mine from a remote server like so:
1 | 0,30 * * * * /usr/bin/wget -O /dev/null http://foobar.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1 |
The above crontab entry runs the Wordpress cron every 30 minutes, on the hour and on the half-hour. That’s easy for me since I have a remote shell account. If you don’t or the world of crontabs is a little bit mysterious to you, you can get a free web based cron account here:
http://www.mywebcron.com/
Once you’ve set-up your freebie account you can configure your cron call thus:
1 | http://foobar.com/wp-cron.php?doing_wp_cron |
Nice and Stable
Good news. Since employing the above strategy, Apache is behaving itself and my sites achieved a 100% uptime during February. There is one little caveat to this news though. At the same time as making these changes to my system, I also installed Monit:
Monit is a free open source utility for managing and monitoring, processes, files, directories and filesystems on a UNIX system. Monit conducts automatic maintenance and repair and can execute meaningful causal actions in error situations.
What all that means is that if Apache does misbehave, Monit will gracefully restart the process and notify me. Since I installed it, Monit hasn’t had to do anything because my system has been OK but it’s a useful addition to my uptime bragging ability! I’ll write about Monit in another post.
