• While dealing with server slowdowns, I’m getting into wp-cron and what it is doing behind the scenes. There are reports of it using a lot of CPU (which happened to me a couple of days back and brought the server to it knees). Installing wp-crontrol, I find that there are a number of cronjobs that really could be run only by the main blog. Each sub-blog has cronjobs that check wp_update_plugins, wp_update_themes and wp_version_check, for instance. These only need to be run once by the main blog; not by each and every sub-blog in the network; they’re redundant.

    Is there a way to do this?

    On another note, logs show that there is strong correlation between FeedBurner GETs and spurious wp-cron runs that immediately follow. There are 5 blogs with 13 scheduled wp-cron runs each – totaling 65 scheduled runs for a 24 hour period. Yet, wp-cron ran 305 times the other day; most of those preceded by a FeedBurner GET! No posts were added or updated during this period and none were set for posting at a later date.

    What’s going on, here, and is there a way to limit this or set RSS-related stuff up in a way such that this doesn’t happen; if indeed Feedburner GETs are a cause?

Viewing 5 replies - 1 through 5 (of 5 total)
  • Cron probably shouldn’t be eating up that much CPU. Can you download the Core Control plugin to get a better look at the various scheduled jobs as well as the update checks?

    I agree that the update checks should only be running on the main blog in the network. There is a related issue I discovered yesterday about this, and the ultimate solution will be to limit update checks to the server. That said, 3.0 is actually (unwittingly) way better at this than MU was. I plan to address this in 3.1.

    The cron gets spawned via a loopback HTTP request, which in turn is triggered by standard pageloads. Feedburner has a knack for hitting your blog at the times that the cron needs to be spawned. (Having the cron triggered by feed readers and search engine crawlers is rather common as they make up a good portion of HTTP requests depending on the size of the site.)

    Nacin

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    🏳️‍🌈 Advisor and Activist

    Applied them to my MultiSites. So far, nothing BAD has happened 🙂

    Thread Starter spherical

    (@spherical)

    Hi Andrew. Thanks for the explanation and for looking at this issue. I applied the patches. We’ll see what happens.

    Did DL and take a look at Core Control. There isn’t a way to modify the cronjobs but I did so using wp-crontrol; setting sub-blog theme, plugin and version checks to non-repeating, just to see if it sticks. May not, as the jobs are called by other sections of WP and they probably will reappear, but it’s worth a shot.

    So you’re saying that cron is triggered by feed and spider accesses or it just looks that way? The pattern is so darn reproducible; indicating that it is the former.

    I’m just trying to determine what caused the 100% CPU, physical RAM exhausted, swap space nearly full problem. The Yandex bot visited, FeedBurner vistited, wp-cron ran and BOOM 6.74 load (normal 0.00-0.35), Error Connecting to Database. This got my attention.

    Thread Starter spherical

    (@spherical)

    IT WORKS! I applied those two Trac DIFFs, as well, and all’s good so far on that front. Thanks, Andrew!

    There’s a further tweak for efficiency. Read about my results here. I could use the blog traffic. 🙂

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘wp-cron – consolidate runs? Prevent unscheduled runs?’ is closed to new replies.