Support » Fixing WordPress » WP 3.0 runaway CPUs after 24 to 72 hours

  • I’ve upgraded to WP 3.0 on two Ubuntu-powered virtual hosts recently and both of them experience a problem with runaway CPUs (4xCPU machine and all CPUs crank to 100% usage).

    It happens unpredictably 24 to 72 hours after restarting Apache (and thus PHP), so we usually have to wait -days- to experience the failure (one failure only took 6 hours but most happen after at least 48 hours of operation). And the -lack- of failure for 48 hours or more doesn’t necessarily mean everything is OK.

    Both installs that fail run 15 to 30 plugins, and in both cases we cut back to minimal plugins (12 or so) to try to associate the runaway CPU with some plugin or other. I run 25+ WP instances on about 10 Ubuntu servers and 2 Mac OSX, professionally, so this is not going to be solved by one of the simple solutions like “install WP Super Cache” – this is something much more esoteric and most definitely associated with 3.0.

    The installs are -moderate- traffic with 250 to 2000 unique visitors a day. And we don’t have the option of turning off -all- plugins to test. The failures -might- be traffic-related because the instance that fails fastest is the one with more traffic.

    Both were upgrades from 2.9.2 where we were running reliably without heavy CPU and without restarting Apache except once a week during system upgrades or log rotation. Plugins that are usual high-CPU usage culprits have been trimmed back, PHP code adjusted, or set to proper settings to reduce their CPU usage. Both installs were running with reasonable CPU usage (‘top’ showing a load around 0.25 or so and CPU load usually around 10%) on WP 2.9.2.

    One of the installs we regressed to 2.9.2 yesterday and it is running without a hitch now, so most likely this is a 3.0 problem, but we won’t know for another 48 hours or more.

    1) I don’t see evidence of anyone else experiencing high CPU load related to WP 3.0 – is anyone?

    2) Does anyone have experience with a way to -profile- PHP on Linux (Ubuntu) in order to understand what’s using the CPU when it goes “hot”?

    Current plugin list for the instances that went “hot” most often:
    Facebook Like Button for WordPress
    Flickr Photo Album
    Role Manager
    Smart YouTube
    Twitter Widget
    WordPress Database Backup
    WP Super Cache
    Yet Another Related Posts Plugin

Viewing 3 replies - 1 through 3 (of 3 total)
  • esmi


    Forum Moderator

    in both cases we cut back to minimal plugins (12 or so) to try to associate the runaway CPU with some plugin or other.

    Try cutting back to zero plugins. Also don’t forget that the theme can have a usage impact, so consider switching to the 2010 theme and monitoring the results.

    I wonder if you know of a way of profiling PHP to understand which part of the system is hogging the CPU when this happens?

    Cutting to zero plugins isn’t an option for us on these sites. They depend on plugins for critical features.

    I have cut to zero on a site that has almost no traffic and that has been inconclusive for us. It does seem that some traffic is required for this to happen.

    I have also analyzed logs at the time of failure and there’s nothing odd in the http logs. Tried setting up WP’s PHP logging but that apparently gives us data only on PHP crashes, which we didn’t have, so gave up on it temporarily.

    Also – your advice about theme CPU usage is good advice for someone who has just switched themes, but we’ve run this theme a couple of years and CPU usage is usually below 10% when pages are being served, so I’m not convinced that the WP 3.0 upgrade would have caused this to happen.

    Also, why would it be sporadic (24 to 72 hours) and why would the CPU usage continue at 100% until I kill Apache? This sounds more like a “looping” bug in the software somewhere than just high but legitimate usage on the part of a theme.

    The usage doesn’t bounce up and down, it just pegs the needle at 100% on all 4 CPUs and keeps them pegged until I shut down Apache. If anything, the term “wedged” applies here. 😉 My guess is that this is in fact some kind of wedging effect where requests build up and overwhelm one process, or where in fact some code does have a flaw that causes a “tight loop” that uses up all CPUs.

    Ah – when it happens – and I have actually watched it happen – one CPU will crank to 100% and then a few seconds later another will crank to 100% and then might be 15 seconds later the third will crank up, and finally the fourth CPU cranks up to 100%. So probably httpd fulfilling a page request for one user, then another, then another, until there are multiple httpd processes each caught up in the fray. I suspect it is being triggered by something that requires a page being served.

    Grateful for any additional thoughts you or others may have.

    (I am upgrading to 3.0 on a Mac OSX server right now and will report if I get more data from that one – I can cut plugins down to just Akismet on that server, once it’s upgraded.)

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘WP 3.0 runaway CPUs after 24 to 72 hours’ is closed to new replies.