Careful with Cron!

6th September 2009

I’ve been strutting my stuff with handy “how-to” posts for a while. Time to eat some humble pie and give you a “how-not-to”…

Cron is a Unix staple for scheduling tasks. WordPress has a scheduling system that’s named after it. I think recently it got a new set of functions to make it easier to work with—things like wp_schedule_event. Anyway, I’m not going to explain it all to you because I don’t know. As I said, I’m going to show you what not to do.

For a client I recently set up a system that grabbed some information from the web page of a venue they were working with so they could display synched-up event information on their site. I got the basics working, and wanted to make sure the information was refreshed regularly. Cue an experiment with wp_schedule_event. It didn’t seem to work, so I left it be.

Recently, checking my server stats, I noticed a warning that requests to one file—the wp-cron.php in my client’s site—were accounting for 25% of all processing time spent on all 8 or so sites on my server! Eeek.

Looking around there seems to be (or have been) some issue with this file generally getting hit too much. That may be a general performance / architecture issue. However, thanks to Simon Wheatley (who has a good introduction to WP’s scheduling), I managed to get a peek at what tasks I had cued up. The plugin Cron View is very handy.

“Ah,” I thought. “Here’s the problem.” There were literally hundreds of events cued up—all for that event-grabbing code I did. I can’t remember the code I used, but for some reason I’d left it on the site for a bit, and it had basically set up a daily scheduled event at every moment that anyone requested a page from the site. I’d taken the code down when I realized it wasn’t working, but I hadn’t noticed the damage it’d done in the background. The site had a few hiccups, but generally ran OK. But my server was heading rapidly to a big monthly overtime bill.

I didn’t really know where all these events were stored. The WP scheduling stuff isn’t well documented, and I guess part of me confused WP’s “cron” with Cron the Unix program, and half-assumed that this humongous list of events was squirreled away in the server somewhere. Luckily the good people on the wp-hackers list helped out.

The events are stored in a field in the wp_options table with the option_name “cron”. If you’re in a fix like mine—with 1 MB of data in the cron field!—just wipe the contents of this field’s option_value via phpMyAdmin.

The default WP check-for-updates events came back in quickly, and my WP-DBManager backup events just needed a “Save” on the options page. Of course, I can’t account for everything else—I’m not sure what’ll happen to scheduled posts. But, in the above kind of situation, the priority is obvious…

Posted in WordPress  |   |