I have a server that is running a number of wordpress blogs, and a number of them have several hundred/thousand posts.

Every couple of days, the server slows to a crawl due to a file being run on Wordpress called WP-cron.php. My entire apache process log turns into this :

http:// imgur.com/A7K9k.png

Times that by quite a bit. And server no go.

Each process takes up about 1.1% of ram. And when we have 50 of them on the go. It gets insane. Not all of them are coming from the same blog, they are pretty widespread. In the Apache process page of WHM, they are usually ALL set to the status of "C", which means closing. But they can sit there until they crash the server, and they still hold the memory.

Just google "wp-cron.php load" and you will find plenty of people with similar issues.

In anycase, we have think it is down to users adding a tonne of dead "pinglists" to their wordpress installation. Which in turn wordpress loops through them endlessly.

Problem number 1. Does anyone have any other suggestions about what would cause the Wordpress file wp-cron.php to loop endlessly. I still think it is down to pings, because all of the people we have contacted about their account load going sky high, have had massive ping lists.

Problem number 2. Even if it is down to excessive pinglists in wordpress. We cannot be babying every single account on the server waiting for it to start spawning the wp-cron processes. It often happens overnight, and I start getting SMS alerts at 2am about the load.

I have CSF installed, which apparently would have ended the processes if they ran over XXX time. But I have been told that it won't catch the processes because they end up in this state of "closing" (They show up as "C" on the Apache page of WHM). Apparently CSF will only kill processes that are "running" which C does not count.

I have seen various other scripts such as : http://dltj.org/article/die-apache-die/ . I took a look at the stat of /proc. But I was boggled at which delimited part was the time running. And if there was any way I could connect it back to an actual Apache process, so that I could see what file was running (So only close connections connected to wp-cron.php, with a state of "C").

Overall I know Problem 2 glosses over the real reason. But I do put the whole thing to excessive pinglists in Wordpress. But I just cannot sit there and babysit every single installation 24/7. So I need a way to save the server when I am not available.

Any help would be much appreciated.


Anychance you can have a different server run the same site, and run cron there? For some of our larger sites, that's what we've done, we've disabled wp-cron on the customer facing web heads, yet have one internally that runs..

Add define('DISABLE_WP_CRON', true); to the wp-config,


Take a look at excellent process watcher/killer, psmon. It's just a Perl script which daemonizes itself background and contains an Apache-style config file with possibility to kill processes if they consume X amount of memory or if they've been consumed X amount of CPU time. PSMon can alert you via syslog or email whenever it decided to slay a process.

Also, you might want to wrap wp-cron.php around a shell script, which would use a lockfile and make sure that only one copy of wp-cron.php is running around any given time.

  • +1, very good program. Especially for targeting runaway processes. – ZazenSec Oct 22 '11 at 7:50

The question is, would your users be confortable not having wp-cron.php.. are your blogs/plugins dependent on them. If not, you can either use mod_security or just plain apache config to blog wp-cron.php from executing. For every blog, WP will run its own instance of wp-config.php.

  • The cron can run. But when it is in a state of "closing" and is stuck there. Especially for minutes at a time, then obviously something went wrong. I don't want to block it 100%, I just want to close it if it runs for an extended amount of time. – user50037 Aug 5 '10 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy