Very High CPU Usage

I have moved my data a few times from backup now (speaking of MySQL). I know how to deal with MySQL DBs, but not sure if I know how do debug one.

The memory usage is about 25MB per process when it serves somethis dynamic and 12MB when stays as a keep alive server (and when probably serves static from wp-super-cache). The problem is that anything I do (optimization wise) I still get about 100% CPU usage for a few seconds every time a dynamic page is accesed. Multiply that by over 1 request per second (which I get in peak hours for dynamic – non cached pages alone) + many more request for static (cached) pages I get a pretty slow server with nothing to do. Like I mention earlier I have a 1.5GHz CPU on this server.

For caching I use WP-Super-Cache with GZip on and WP-Cache.

Later Edit: My load average is always above 1, with a medium of 2-3 and even over 5 at peak times. The Apache server is configured as best as I could for the small amount of ram I have (just 256MB so just 8 Max Clients).

Any of you having poor performance because of using PHP5 instead of PHP4?

Your memory usage is very low, I use several times that on many of my WordPress sites for each instance, depending on what’s being accessed. Although, I’d highly recommend upgrading your RAM.

As for your CPU usage, it’s very normal and common for large amounts of PHP being executed to result in a short spike. If the problem is with your dynamic pages being created, I would think that the solution would be to have them cached so they’re served as static pages.

I will buy a new server. Now I’m running just on a test box which I put together in a hurry.

From your past experience do you consider to be absolutely normal to have every page generated in around 5 seconds on a 1.5GHz box (the times are saved by wp-super-cache)?

hallsofmontezuma: Hmm, maybe something wasn’t configured right? The past couple days I’ve had some large traffic spikes (about 45,000 page views / day). Server load has remained around 0.20 – 0.40 all day. My WordPress doesn’t have as many categories, but has around 4000 posts, and I’m running a vBulletin forum on top of it.

I’ve never used lighttpd without XCache, though, so maybe that is helping quite a bit.

I find myself in a pretty strange situation. Obviously it’s not Apache (because the load times were long on the shared hosting too) and not MySQL (because there the load is decent). Also I have changed all the files in the installation many times so I suppose I have changed pretty much everything in the WordPress platform. Not sure what I can try next.

What do you mean you’ve “changed pretty much everything in the WordPress platform”?
If you mean you’ve edited the PHP from the default installation, then that is very possibly the cause. The fact that your permalinks management page takes forever to load indicates such. As far as the management interface goes, loading the edit a post and manage categories pages are the most CPU intensive, not the permalinks page.

I mean by removing everything instead of my pictures inside wp-content when I update.

I don’t remember editing anything else that the theme. No work on the platform (which would anyway be gone on the update). Also tried the default theme and still get sight CPU usage and also disabling all the plug-ins.

How much RAM and CPU time does a dynamic process of Apache use for you? Do you have PHP4 or PHP5?

On a faster server, I have dual 2.9GHz processors, 8GB RAM, and PHP 5.

Depending on the particular site and particular dynamic page, it’s not uncommon for one instance to take up the bulk of the processors and 70 or so meg of RAM for a brief moment.

What plugins have you installed? Keep in mind, disabling a plugin doesn’t always mean getting rid of its effects. If the plugin changed some PHP code or a table, you could have lasting effects from it.

Pretty powerful server you got there. Is it a disrespect to ask what sites are you keeping on it?

You are totally right about this plug in thing… I know it but didn’t think about it when I made the statement about plug ins… I have Akismet, Feedburner FeedSmith, Google Sitemaps, WordPress DB Backup, WP-ContactForm and WP Super Cache activated.

From your experience it is possible for a faulty (for various reasons; like I’ve said I’ve imported/exported the DB entirely through phpMyAdmin, had about 5 different versions of WordPress with that DB, had different plugins that I used over the time and last but not least the export size of the DB is 30MB) DB to have an impact on Apache’s CPU usage instead of MySQL?

On that particular server, about 10 or so WordPress sites make less than 10% of the websites served.
There’s really no way without looking at your database to know what your problem is. Those are all very common plugins, but again, plugins you have had in the past could still leave their marks.
A 30MB database is pretty massive for WordPress, but the size of the database alone wouldn’t be slowing things down. It would depend on the size of the actual tables.
I feel like a plugin or some combination of plugins that you’ve had in the past have left undesirable junk in your database, but like I said, there’s no way for anyone to know for certain without looking. Just knowing that you have a slow site can mean many things.

5000 page views a day, something is wrong, I have other sites, pushing 50,000 a day, on an 800Mhz machine, OS X, minimal ram, just hums along.

You say you are using super cache and wp-cache, are you sure you can use both at the same time? I also see you have gzip compression on, which as far as I remember, at least with wp-cache, you can not turn that on, as it causes issues.

This should be a pretty simple problem to test if you want to see where the trouble is.

So you have good ole Brit here:
https://www.thecelebrityblog.com/2008/04/britney-spears-reunites-with-former-manager/

I am showing that page loads as:
<!– Dynamic Page Served (once) in 13.472 seconds –>
<!– Cached page served by WP-Cache –>
<!– Compression = gzip –>

Now, you need to load the page, view html source on it, and copy all the source code to a file, call it index.html

Now, ftp/ssh into your server, and make the following directory path:
/2008/04/britney-spears-reunites-with-former-manager/
Drop index.html into it.

Now, go into wordpress and take the post offline.
Load this url:
https://www.thecelebrityblog.com/2008/04/britney-spears-reunites-with-former-manager/index.html

So this is pure static now, the server is not talking to php or the database. Does it load fast? I am going to guess it does. Though you may have to boot all current users out of apache.

Assuming it loads fast, you now know your server is fast enough, it is just a matter of tuning things better. Assuming your cache plug ins are working, mysql should be dead silent, but what does top say about mysql?

You have 5000 users a day, that should be nothing, you should be able to serve that out on a old 500mhz box.

First, thanks for all your kind responses.

Second, WP-Super-Cache has an option of using both wp-super-cache and wp-cache (it knows how, and uses the first one for guests and second for logged in users). The server is really fast with second to none CPU usage when serving static pages (I can test that by loading a page already cached through LAN). The problem, as you can see by how long it took to dynamically serve that page (13 seconds) things are really slow when not serving of the cache. For example, when I have a few dynamically served pages in a few seconds things slow down so much than the next readers (including me, for example) wait a couple of seconds of more just to get a cached page, due to CPU blockage.

On top MySQL has a 1/5 CPU load compared to Apache2 when a dynamic page is loaded. That’s why I asked if it’s possible for a PHP (Apache served page) to be slowed down by a faulty DB.

Later Edit: Is there any logical reason why 5.000 posts have 12MB and wp-options has 19MB with 9MB overhead? Did a optimize tables on wp-options and now I’m left with about 11MB on it.

If you think that the database queries might be taking a long time, there’s a way to tell:

Put this in wp-config.php:
define('SAVEQUERIES', true);

Put this in your theme’s footer.php:

<?php if ( current_user_can('manage_options') ) {
echo "<!--\n";
var_dump($wpdb->queries);
echo "\n-->";
} ?>

Now, the SQL queries that it makes will be saved, and the results will be visible on any page when you are logged in as an administrator.

The query information will be a big array of lots of stuff. Each row will have:
1. The SQL of the query.
2. How long it took to run (milliseconds).
3. What internal function called the query.

This is useful for analyzing database bottlenecks.

Remove that code after you’re done, because saving queries does add a fair bit of time to page generation.

OK. So Firefox is a little busy opening -rewrite_rules- in phpMyAdmin. Looks like a have a lot of rewrite rules in my wp-options table (which I found on Google that are responsible with permalinks). Anyone could tell me how big their wp-options table is and how large their rewrite_rules in there are?

I have a feeling we’re getting somewhere.