Skip to:

Performance problem 100% CPU

  • javicarrasco


    Probably it is not Buddypress fault. We launched with buddypress and we have very strong performance issues.

    Now we are on a 3,9GHz CPU – 4GB Ram VPS. and twice a day we get 100% CPU usage. We disabled almost every plugin without luck and deleted post revisions. We are using wp-supercache fully working but it doesn’t solve the problem. Nor eAccelerator did.

    We have changed hosting company twice but it didn’t help.

    wp-devel says 99% of the time spent is PHP’s fault, SQL queries just 1%.

    I don’t know how to find the problem.

    We are using wordpress mu 2.8.6, buddypress 1.1.2

    Any ideas?

    Thank you

Viewing 14 replies - 1 through 14 (of 14 total)

  • John James Jacoby


    Any server admin types want to chime in on this one?

    I want to respond with the typical “Does it happen when BP is not active? Check your access logs/Check your PHP config” answers, but that doesn’t solve the problem.



    VPS is not the same as dedicated even though it’s close.

    Not sure how many visitors you get per day, but on my home install (this pc) I got 100 visitors at a certain moment on my buddypress driven site and it didn’t even went over 10% (that while running a lot of other crap, like firefox and photoshop).

    Setup: 3.07 GHz (i7 950) and 6 GB Ram.

    Why not try running a simple script (maybe GD or something) outside of wordpress and see if you get 100% CPU, if it doesn’t, then accuse wordpress.

    Jeff Sayre


    Andrea Rennick


    Without being able to look and see multiple files both within the wordpress part and the server, the most we can do is guess.

    Some things I have seen crank the CPU:

    – a bad plugin with an off query

    – bad code in the theme (make the theme more efficient, revert to default theme to see if that’s the issue)

    – inappropriate server settings. Did you really put in a wildcard subdomain (if you use them) or do you have, say 20, listed. (Seen it. Wasn’t pretty.)

    – default server settings on high traffic sites. Preforks, child processes – all these can be streamlined.

    – an obscure bug with cPanel on CentOS boxes that create a memory leak

    – in rare cases a hardware failure

    and finally – being hit with spammers constantly. I have a couple older domains, and no matter where I host them, the simple fact they are “out there” mean they get hit with an INSANE amount of spam. Email, comments, splogs – all of it.

    Basically, you have to eliminate what it isn’t.

    how much traffic do you get? How big is the database?



    Thank you all.

    Jeff I won’t try compression now because It could increase the CPU usage and this is our main problem. When it resolves we will do.

    We have around 6000 page views a day.

    Probably we have a very inefficient code somewhere but I don’t know how to find it. I reviewed several times the main blog theme and random files from the plugins but I couldn’t find it. I have just read about Xdebug, ¿Have you worked with It?

    We have a wildcard subdomain.

    I am not a server administrator but the VPS is fully managed and I think the guys managing it are good and we have migrated from another hosting company where we had the same problem.

    ¡We have cPanel and CentOS! ¿Could that bug be the problem?

    The spam is not a big problem, some comments but not too much.

    Thank you again

    Jeff Sayre



    Jeff I won’t try compression now because It could increase the CPU usage and this is our main problem.

    That is not correct. It will increase CPU usage the first time a PHP page’s output is compressed. But, from that point forward, only the compressed data will be served. This can significantly decrease as server’s CPU usage. Now, when you clear the compressed cache, it will have to recompress all over.

    Is zLib compression the same thing / idea as Zend eAccelerator? I installed eAccelerator on my server and it made a huge difference. Wondering if I should also enable zLib?

    Answered my own question. They are different. But some people have issues trying to use both:



    Thank you,

    Jeff is it different than using wp supercache with compression activated?



    I have been doing some debugging. I have modified plugin.php to record how much time takes (using microtime) to execute every do_action() call.

    Look at the results following, it doesn’t look like a code performance problem of any plugin, or at least, it doesn’t happen every time.

    muplugins_loaded: 1.2E-5,


    _auth_cookie_malformed: 1.5E-5,

    _auth_cookie_valid: 1.4E-5,

    _set_current_user: 0.000413,

    _xprofile_setup_globals: 1.4E-5,

    _bp_core_setup_globals: 1.4E-5,

    _bp_activity_setup_globals: 1.2E-5,

    _bp_blogs_setup_globals: 1.3E-5,

    _bp_forums_setup: 1.4E-5,

    _friends_setup_globals: 1.3E-5,

    _groups_setup_globals: 1.4E-5,

    _messages_setup_globals: 1.4E-5,

    _bp_wire_setup_globals: 1.3E-5,

    _xprofile_setup_globals: 1.3E-5,

    _bp_status_setup_globals: 1.3E-5,

    _events_setup_globals: 1.7E-5,

    _bp_activity_setup_nav: 1.8E-5,

    _bp_blogs_setup_nav: 1.9E-5,

    _bp_blogs_register_activity_actions: 1.7E-5,

    _friends_register_activity_actions: 1.7E-5,

    _groups_setup_nav: 1.8E-5,

    _groups_register_activity_actions: 1.6E-5,

    _messages_setup_nav: 1.7E-5,

    _bp_wire_setup_nav: 1.6E-5,

    _xprofile_setup_nav: 1.7E-5,

    _xprofile_register_activity_actions: 1.6E-5,

    _bp_status_register_activity_actions: 1.6E-5,

    _events_setup_nav: 1.8E-5

    : -0.674134,

    sanitize_comment_cookies: 0.000702,

    setup_theme: 6.4E-5,


    _widgets_init: 0.013721,

    _wp_ajax_: 2.3E-5

    : 0.137118,

    posts_selection: 2.0E-5,

    friends_setup_nav: 2.20000000001E-5,

    xprofile_screen_display_profile: 3.99999999999E-5,


    _switch_blog: 2.3E-5,

    _switch_blog: 2.0E-5

    : 0.00442,

    get_header: 2.89999999999E-5,


    _wp_enqueue_scripts: 0.002232,

    _wp_print_styles: 0.001407,

    _wp_print_scripts: 0.000719,

    _wp_print_scripts: 0.000699,

    _wp_print_scripts: 0.000655,

    _signup_header: 5.5E-5,

    _wp_print_styles: 0.001295,

    _wp_print_styles: 0.001268

    : 0.0585,

    posts_selection: 2.49999999999E-5,

    posts_selection: 3.1E-5,

    get_sidebar: 3.6E-5,

    get_footer: 3.0E-5,


    _bp_adminbar_logo: 0.000711,


    __switch_blog: 3.29999999999E-5,

    __switch_blog: 3.30000000001E-5,

    __bp_adminbar_random_menu: 3.00000000001E-5

    _: 0.031586,

    _wp_print_footer_scripts: 2.6E-5

    : 0.068475



    @Andrea_r can you give me a link to that bug with cPanel on CentOS boxes?



    @javicarrasco, I am on an unmanaged dedicated box and I used to use cPanel, and I had the same problem you have. I went with cPanel because I did not have to worry about installation. However, I nixed it and decided to go with a control panel that I use on all of my dedicated boxes. You may want to do a google search for log files that cPanel creates. I found that the plethora of log “files” being created by cPanel for every little thing was my issue.

    Andrea Rennick


    this help any?

    A quick google found plenty of mentions of that memory leak.

    Ron Rennick


    Another possibility is a large table in the database that is having frequent data insertions/changes/deletions.

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Performance problem 100% CPU’ is closed to new replies.
Skip to toolbar