Very High CPU Usage

Otto, following code generates 404 error, right after adding it to wp-config.php

define('SAVEQUERIES', true);

I had this upgrade problem on a website previously running WP 2.3.3. After I put 2.5 the server was down in a few seconds. Put WP 2.3.3 back and no problem since then. Best to have a test box for this, maybe a separate hosting account. Not the best practice to test things (like new WP versions on old DBs) on the production box/hosting.

Hope you have all the previous backups…

check java script for what?

the following is from an admin person with my hosting server.

Hello,
It appears that there is an issue with wordpress 2.5. I’ve tried replacing the original files from www.ads-software.com for version2.5 on your site and still have the same problem. It appears that the javascript is causing some problems. I would recommend contacting wordpress support by posting on their forums or downgrading this back to the previous version.

We have found similar issues reported by other users of wp2.5, https://www.ads-software.com/support/topic/164276
We have also tried the fix listed here but did not correct the problem. Please post your details of the problems you are having at https://www.ads-software.com/support/ or we recommend downgrading to the version in fantastico.

anyone want to give me a hand?

Okay, just adding my help/recent experience to this post. One of our sites we use WP to manage is Basketball New Zealand. Now, we run a lot of our sites using WP, and to be honest, I’ve been a huge WP fan since… forever. However, with a site like BBNZ, it worries me no-end how massive this site is now, and how much traffic it gets, and the server load etc etc etc…

In particular, the wp-options table continually needs massaging and some TLC. Case-in-point this morning, I arrive at work and find the entire website is down. I start investigating, optimize everything I can find, search the forums (and of course find this thread) and start figuring out the best plan off attack.

I’ve been worried about the size of the wp-options table for a while, and it reached nauseating heights this morning when it’s size had peaked to 31MB!!

@mihaim, deleting all re-write rules is definitely the solution that saved us from early-morning cardiac arrest.

Each row was about 1.5mb and we had 18 exact copies of this row in the database! Deleting them fixed it. What worries me is, why is this happening??

There also seems to be a large amount of rows called ‘template’ with the value being ‘default’ (btw, we’ve re-named our theme to default, as WP was randomly dropping our theme named BBNZ and reverting back to the default theme without asking our permission, *sigh*, yet another forum search to find a frustrating solution…). I am unsure why this is and any feedback would be cool.

@dodge107, perhaps these ARE bugs worth logging…?

Happy backing-up everyone. ??

If it’s too large is bad. WP-Options should be around 1MB (that’s what I have with over 5000 pages). If it’s larger than that or has more than one instance of cron or permalinks or rewrite_rules, etc. it’s bad and you should delete them after you have made a proper backup. Also optimize the tables when you finish editing them. Use phpMyAdmin for all there processes.

P.S. Imagine how useful was for me to find the solution after I got banned a few times from shared hosting, killed my server with 0.5 requests / second, etc.

I have 2,061 posts and 314 pages. My wp-options table has 362 records and is 8.2 MB. I think this may be what is causing high CPU load on my blog.

I’ve had a look in it using phpMyAdmin but from what I can tell there is only one instance each of cron, permalinks and rewrite_rules. However I only barely know my way around phpMyAdmin and am not confident to do much more than repairing and optimising tables.

It does seem there are quite a lot of references in wp-options to plugins I no longer use.

What can I do to reduce its size? I’ve got an angry host threatening to close my site so I’d be very grateful for help.

I had trouble with the wp-options table going corrupt, untill i stopped using the built in cron function. I used it to process some external RSS feeds.

Is anyone else with wp-options trouble using the cron function?

I’ve been running into this same issue attempting to run the upgrade scripts and have it narrowed down to the rewrite_rules add_option attempt.

rewrite.php ~line 856
update_option(‘rewrite_rules’, $this->rules, true);

In the update_option function, line 109
add_option( $option_name, $newvalue, ”, ‘yes’, 1);

Just sits there and hangs on the following query:
INSERT INTO wp_options (option_name, option_value, autoload) VALUES (‘rewrite_rules’, ‘a:63:{s:11:\”robots.txt$\”;s:18:\”index.php?robots=1\”;s:15:\”.*/wp-atom.php$\”;s:19:\”index.php?feed=atom\”;s:14:\”.*/wp-rdf.php$\”;s:18:\”index.php?feed=rdf\”;s:14:\”.*/wp-rss.php$\”;s:18:\”index.php?feed=rss\”;s:15:\”.*/wp-rss2.php$\”;s:19:\”index.php?feed=rss2\”;s:15:\”.*/wp-feed.php$\”;s:19:\”index.php?feed=feed\”;s:23:\”.*/wp-commentsrss2.php$\”;s:34:\”index.php?feed=rss2&withcomments=1\”;s:32:\”feed/(feed|rdf|rss|rss2|atom)/?$\”;s:27:\”index.php?&feed=$matches[1]\”;s:27:\”(feed|rdf|rss|rss2|atom)/?$\”;s:27:\”index.php?&feed=$matches[1]\”;s:20:\”page/?([0-9]{1,})/?$\”;s:28:\”index.php?&paged=$matches[1]\”;s:41:\”comments/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:42:\”index.php?&feed=$matches[1]&withcomments=1\”;s:36:\”comments/(feed|rdf|rss|rss2|atom)/?$\”;s:42:\”index.php?&feed=$matches[1]&withcomments=1\”;s:29:\”comments/page/?([0-9]{1,})/?$\”;s:28:\”index.php?&paged=$matches[1]\”;s:44:\”search/(.+)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:40:\”index.php?s=$matches[1]&feed=$matches[2]\”;s:39:\”search/(.+)/(feed|rdf|rss|rss2|atom)/?$\”;s:40:\”index.php?s=$matches[1]&feed=$matches[2]\”;s:32:\”search/(.+)/page/?([0-9]{1,})/?$\”;s:41:\”index.php?s=$matches[1]&paged=$matches[2]\”;s:14:\”search/(.+)/?$\”;s:23:\”index.php?s=$matches[1]\”;s:47:\”category/(.+?)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:52:\”index.php?category_name=$matches[1]&feed=$matches[2]\”;s:42:\”category/(.+?)/(feed|rdf|rss|rss2|atom)/?$\”;s:52:\”index.php?category_name=$matches[1]&feed=$matches[2]\”;s:35:\”category/(.+?)/page/?([0-9]{1,})/?$\”;s:53:\”index.php?category_name=$matches[1]&paged=$matches[2]\”;s:17:\”category/(.+?)/?$\”;s:35:\”index.php?category_name=$matches[1]\”;s:42:\”tag/(.+?)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:42:\”index.php?tag=$matches[1]&feed=$matches[2]\”;s:37:\”tag/(.+?)/(feed|rdf|rss|rss2|atom)/?$\”;s:42:\”index.php?tag=$matches[1]&feed=$matches[2]\”;s:30:\”tag/(.+?)/page/?([0-9]{1,})/?$\”;s:43:\”index.php?tag=$matches[1]&paged=$matches[2]\”;s:12:\”tag/(.+?)/?$\”;s:25:\”index.php?tag=$matches[1]\”;s:47:\”author/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:50:\”index.php?author_name=$matches[1]&feed=$matches[2]\”;s:42:\”author/([^/]+)/(feed|rdf|rss|rss2|atom)/?$\”;s:50:\”index.php?author_name=$matches[1]&feed=$matches[2]\”;s:35:\”author/([^/]+)/page/?([0-9]{1,})/?$\”;s:51:\”index.php?author_name=$matches[1]&paged=$matches[2]\”;s:17:\”author/([^/]+)/?$\”;s:33:\”index.php?author_name=$matches[1]\”;s:69:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:80:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&feed=$matches[4]\”;s:64:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/(feed|rdf|rss|rss2|atom)/?$\”;s:80:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&feed=$matches[4]\”;s:57:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/page/?([0-9]{1,})/?$\”;s:81:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&paged=$matches[4]\”;s:39:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/?$\”;s:63:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]\”;s:56:\”([0-9]{4})/([0-9]{1,2})/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:64:\”index.php?year=$matches[1]&monthnum=$matches[2]&feed=$matches[3]\”;s:51:\”([0-9]{4})/([0-9]{1,2})/(feed|rdf|rss|rss2|atom)/?$\”;s:64:\”index.php?year=$matches[1]&monthnum=$matches[2]&feed=$matches[3]\”;s:44:\”([0-9]{4})/([0-9]{1,2})/page/?([0-9]{1,})/?$\”;s:65:\”index.php?year=$matches[1]&monthnum=$matches[2]&paged=$matches[3]\”;s:26:\”([0-9]{4})/([0-9]{1,2})/?$\”;s:47:\”index.php?year=$matches[1]&monthnum=$matches[2]\”;s:43:\”([0-9]{4})/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:43:\”index.php?year=$matches[1]&feed=$matches[2]\”;s:38:\”([0-9]{4})/(feed|rdf|rss|rss2|atom)/?$\”;s:43:\”index.php?year=$matches[1]&feed=$matches[2]\”;s:31:\”([0-9]{4})/page/?([0-9]{1,})/?$\”;s:44:\”index.php?year=$matches[1]&paged=$matches[2]\”;s:13:\”([0-9]{4})/?$\”;s:26:\”index.php?year=$matches[1]\”;s:58:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/attachment/([^/]+)/?$\”;s:32:\”index.php?attachment=$matches[1]\”;s:68:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/attachment/([^/]+)/trackback/?$\”;s:37:\”index.php?attachment=$matches[1]&tb=1\”;s:88:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:49:\”index.php?attachment=$matches[1]&feed=$matches[2]\”;s:83:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$\”;s:49:\”index.php?attachment=$matches[1]&feed=$matches[2]\”;s:57:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)/trackback/?$\”;s:85:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&name=$matches[4]&tb=1\”;s:77:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:97:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&name=$matches[4]&feed=$matches[5]\”;s:72:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)/(feed|rdf|rss|rss2|atom)/?$\”;s:97:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&name=$matches[4]&feed=$matches[5]\”;s:65:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)/page/?([0-9]{1,})/?$\”;s:98:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&name=$matches[4]&paged=$matches[5]\”;s:57:\”([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)(/[0-9]+)?/?$\”;s:97:\”index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&name=$matches[4]&page=$matches[5]\”;s:47:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/([^/]+)/?$\”;s:32:\”index.php?attachment=$matches[1]\”;s:57:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/([^/]+)/trackback/?$\”;s:37:\”index.php?attachment=$matches[1]&tb=1\”;s:77:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:49:\”index.php?attachment=$matches[1]&feed=$matches[2]\”;s:72:\”[0-9]{4}/[0-9]{1,2}/[0-9]{1,2}/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$\”;s:49:\”index.php?attachment=$matches[1]&feed=$matches[2]\”;s:25:\”.+?/attachment/([^/]+)/?$\”;s:32:\”index.php?attachment=$matches[1]\”;s:35:\”.+?/attachment/([^/]+)/trackback/?$\”;s:37:\”index.php?attachment=$matches[1]&tb=1\”;s:55:\”.+?/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:49:\”index.php?attachment=$matches[1]&feed=$matches[2]\”;s:50:\”.+?/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$\”;s:49:\”index.php?attachment=$matches[1]&feed=$matches[2]\”;s:18:\”(.+?)/trackback/?$\”;s:35:\”index.php?pagename=$matches[1]&tb=1\”;s:38:\”(.+?)/feed/(feed|rdf|rss|rss2|atom)/?$\”;s:47:\”index.php?pagename=$matches[1]&feed=$matches[2]\”;s:33:\”(.+?)/(feed|rdf|rss|rss2|atom)/?$\”;s:47:\”index.php?pagename=$matches[1]&feed=$matches[2]\”;s:26:\”(.+?)/page/?([0-9]{1,})/?$\”;s:48:\”index.php?pagename=$matches[1]&paged=$matches[2]\”;s:18:\”(.+?)(/[0-9]+)?/?$\”;s:47:\”index.php?pagename=$matches[1]&page=$matches[2]\”;}’, ‘yes’)

Unless I’m missing something, the VALUES section of a SQL insert statement doesn not have 2 parameters, unless this is something new to MySQL.

I have had to have the cron process killed because it is hanging up and causing too many processes. This may indeed be the problem.

I found my wp-options file had many instances of something called Magpie RSS in it, presumably an RSS feed caching tool.

I deleted all of those row which reduced the wp-options table from over 8Mb to less than 1Mb. However within 12 hours they had all returned.

I had been using an RSS plugin to add RSS feeds on a couple of pages so I found and deleted every instance of that, and then deleted all the Magpie RSS rows again.

18 hours later the wp-options file is still less than 1Mb and there’s been no repeat of the high CPU load I was experiencing before. Fingers crossed…

Here’s an unusual variation… All of you are talking about the ‘rewrite’ hanging and the wp_options table getting enormous. I’m working on something that’s got less than 500 items in wp_options. I’m confident that rewrite is the problem, but it does not slow down the Admin section.

It seems that whenever the server is not accessed for a while (application is sleeping), and I try to access the site, only the Index page shows up. All other pages ‘hang’ when using mod_rewrite.

The site: https://italianice.net
I also modified the .htaccess file to redirect the older files.
I didn’t find any info saying that this could be a problem.
I’m at a loss! Can any of you geniuses shed some light?

Thanks.

dang, Im having the same issues as well. High CPU usage. I optimized all my tables and Im still getting it. Its been since I’ve upgraded to 2.5+…

I’m not a guru when it comes to tables so I dont want to start dropping things without knowing what Im doing. Please help!

7milesdown – how big is your wp-options table?

If you are running WordPress on a Go Daddy hosting account and have this issue, please contact our support team. When contacting us provide custom database queries, mods, the domain name and send this information to [email protected]. Thank you.

Alicia R.
Go Daddy Hosting

Hello,

I’ve been following this thread for a little while with the same problem.

My wp-options was about 34MBs and one day my site just refused to load.

I recently fixed it and got the same problem again today and I think I just fixed it for a second time (fingers crossed). Here’s what I did:

1st Fix:
In phpmyadmin, i exported the wp-options table (excel). Found about 15 rows of “rewrite_rules” which turned out to be exactly the same in each row. Each of those rows were about 2mb each. Looking at it, i discovered that it was one of my ‘posts’ that caused the problem. I noticed this when i saw the same post name repeated over and over. I went in to wp manage and drafted that one post. Problem fixed. 3 days later, problem came back.

2nd Fix:
My wp-options is now 7mb. Again in phpmyadmin, i exported the wp-options table (excel). Again i discover that there is still traces of that one post that caused problem. Although i got rid of the post that caused the problem, there were images still associated with that post. I looked thru my wp uploads in wp admin and found those images and deleted them in wp-admin. If you have the same problem, delete the files in wp and not ftp. Since deleting in ftp will leave traces of those files in wp.

Hope this helps someone.

I am getting this same problem, my wp-options is showing an abnormal size and resource usage. I am going to implement the fixes above (from liquid rice) and see what happens. I appreciate it, and I’ll keep everyone updated as to what happens. The site is recetas de postres

For the record, WP-Super Cache seems to have helped as well.