So, since about WordPress 3.6 I’ve had a problem with CPU overload on my blog. Mostly, I think, visitors won’t have noticed, but for me, on the backend, it’s been a royal pain: it occasioned my recently changing my theme, and has made posting a real chore. (Write. Copy text version. Click Publish. Wait and see if it goes through, or bounces.)
My CPU was being overloaded by the WordPress script admin-ajax, which, if you do some research, supposedly gets called sometimes by a badly designed plugin. Except, I checked all my plugins, and they didn’t seem to be the cause of the problem.
Turns out there’s some kind of API feature that was added to WordPress in version 3.6, called the Heartbeat API. Everytime I leave the admin access panel open on my site overnight by accident, the CPU was basically hogged to death. This seems to have caused a lot of problems for a lot of people, but the last time I searched for a solution, I couldn’t find one. Today, though, I found this post discussing the issue, and using the code inside it, I seem almost in a single shot to have solved my overload problems.
I think. We’ll see. Everytime I post something about having solved this problem, I regret it a day or two later. But the change in my site’s behaviour has been so rapid, after adding this code to the functions.php for my current template, that I can’t help but feel optimistic.
Oh, and for those who want to fine-tune it a little more, check this out.
New post: WordPress’ admin-ajax CPU Problem: Finally, a Solution http://t.co/77QPLPXx03
Did this resolve your issue with the admin-ajax.php CPU overload? I’m having the same problem on SIteground…and upgraded my hosting plan for the moment but can’t seem to figure out what the issue is.
Not completely, but it seems to have been a partial resolution… though it broke scheduled posting, which is something to look out for!
One thing that did help me was that my (usually pretty nice) hosting service’s support people finally (!) informed me that the caching plugin I was using doesn’t play well with their hosting environment. (Only took them a year of problems to come up with that, though to be fair they often disclaim any knowledge of WordPress!) You might look at your caching software and reevaluate how well it’s working for you.
Between disabling the heartbeat in my theme function page with this code:
add_action( 'init', 'stop_heartbeat', 1 );
function stop_heartbeat() {
global $pagenow;
if ( $pagenow == 'index.php' && $pagenow != 'post.php' && $pagenow != 'post-new.php' )
wp_deregister_script('heartbeat');
}
… and changing my caching software to the one recommended by my hosting service, I’m back down to the proper amount of CPU minutes consumed (okay, well, I mean my maximum, give or take a minute or two). That’s probably still excessive for a site like mine, but it keeps ’em out of my hair till I can afford a proper professional site redesign with all the plugin stuff hardcoded into the template.
Beyond caching software and selectively disabling the heartbeat api, it might be a bad plugin that’s overloading it, or just too many plugins. I sometimes use P3 Plugin Profiler to check whether any plugin is acting weird, though you have to be careful to understand its output. (Sometimes a plugin looks like a baddie but it’s just the profiling software making it seem that way.)
Also, if you haven’t adjusted your WP-Cron function–setting a Cron Job manually in your control panel, to reduce the load, you might look at that. WP-Cron can be pretty aggressive on some systems.
Good luck!