htaccess pointing to wordpress makes CPU overload

[cisoprogressivo]

On a fresh install of wordpress (with or without the default theme, with or without a fresh database) the load of my VPS is about 0.10/0.50 (it's a quite big website: 6000 unique visitors per day).
When creating the wordpress lines on my .htaccess the load goes up to more than 40/50 and the the VPS crashes.
This happens also if in Wordpress is not selected to use permalink (so if I past by myself the code in htaccess).
The code I'm talking about is:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Also my hosting is investigatin without results.
Other people seems to have this problem in past:
​http://www.wordpress.org/support/topic/243147
​http://www.wordpress.org/support/topic/232974

[miqrogroove]

mod_rewrite isn't part of WordPress though. Have you looked at Apache support?

[cisoprogressivo]

Hi,

mod_rewrite is working as intended. On the same machine/domain I use it for a wiki (with mediawiki) and a forum (with phpBB)

[cisoprogressivo]

The pasted htaccess code is automatically generated by wordpress when I activate pretty permalinks. When this option is enabled, many php processes are created, and they keep running and overloading the server, so the problem is not with mod_rewrite. Wordpress works as intended with "ugly permalinks".

[miqrogroove]

Okay, well you need to be clear about whether the processes are mod_rewrite processes or PHP processes. Are you able to find out? Trac is for bug reporting, not for technical support. To keep this ticket open there has to be a problem in WordPress, and so far all we know is that your server has some runaway processes?

I'm not sure if this will help, but I added an optimization ticket #11845

[cisoprogressivo]

as you can see from the screenshots, when pretty permalinks are enabled I get a lot of php runaway processes and an high cpu load. Viceversa, when I disable them, I don't have any runaway process and the server load is low. Please note that I get this results by enabling and disabling the option via the wordpress admin panel, so I never edit htaccess directly.

[Denis-de-Bernardy]

See #11845. And svn export the following plugin to see if it spots anything:

​http://svn.wp-plugins.org/health-check/branches/alpha/

[cisoprogressivo]

Already tried suggestions in #11845
With Health Check i got this message:
RECOMMENDATION: WordPress failed to detect mod_rewrite on your Webserver, thus disallowing the use of fancy urls. Please contact your host to have them fix this.

but it doesn't make any sense. I use (successifully) mod_rewrite for the wiki and the forum.

[cisoprogressivo]

I got this message too:

RECOMMENDATION: Your Webserver does not have Apache functions. At worst, this can prevent WordPress from detecting Apache's mod_rewrite module, thus disallowing the use of fancy urls. At best, this makes detecting the mod_rewrite module slower. Please contact your host to have them fix this.

[cisoprogressivo]

I tried this plugin on different hosting with wordpress site with mod_rewrite properly working and I got the same message, so I think that it doesn't mean anything.

[Denis-de-Bernardy]

What the message means, is, if you have your host enable the apache functions, WordPress will detect mod_rewrite using apache_mod_loaded() instead of trying to find it using phpinfo() and an output buffer. The latter method fails (as done on your server) when phpinfo() doesn't return the apache modules. (Thanks for the feedback, too. It helps to know it wasn't clear enough.)

I'm suspecting it's the issue, too. I'm assuming this is a live server, so let's try a live diagnosis. In functions.php, there is a apache_mod_loaded() function:

function apache_mod_loaded($mod, $default = false) {
	global $is_apache;

	if ( !$is_apache )
		return false;

	if ( function_exists('apache_get_modules') ) {
		$mods = apache_get_modules();
		if ( in_array($mod, $mods) )
			return true;
	} elseif ( function_exists('phpinfo') ) {
			ob_start();
			phpinfo(8);
			$phpinfo = ob_get_clean();
			if ( false !== strpos($phpinfo, $mod) )
				return true;
	}
	return $default;
}

get_mod_rewrite() calls it with a default of true.

please change:

			$phpinfo = ob_get_clean();
			if ( false !== strpos($phpinfo, $mod) )
				return true;

to:

			$phpinfo = ob_get_clean();
$count = get_option('check_mod_rewrite_counts');
update_option('check_mod_rewrite_counts', ++$count);
			if ( false !== strpos($phpinfo, $mod) )
				return true;

then in wp-config.php, *after* WP is loaded, add:

if ( isset($_GET['test']) )
  echo get_option('check_mod_rewrite_counts');

and then visit yoursite.com?test

It might be that your site is calling the mess on every page load for some reason.

[dd32]

IMO, apache_mod_loaded needs to have a transient cache of its value.. Doing that would reduce the number of times it was called for sure. Perhaps it could just be used for the phpinfo() branch..

[Denis-de-Bernardy]

I don't think the transient would change much, since the function isn't supposed to get called on the front end.

My initial thought was verbose rewrite rules, but health check ruled that out. Then the couple suggestions I posted in #11845, which usually help.

Next in line would be, the rewrite rules getting re-created on every page load for some reason. I recently had that on my own server while debugging my object cache. Things got very resource intensive when it occurred, and it was very hard to track down.

Last options I can see are large numbers of 404 errors (such as favicon.ico requests), or a plugin that is messing around with the various permalink filters.

[dd32]

Oh right, I forgot about that..

Sounds like its being cleared every load alright. Which brings to why its happening on a clean install then..

[Denis-de-Bernardy]

Replying to dd32:

Sounds like its being cleared every load alright. Which brings to why its happening on a clean install then..

In my case, I had a misplaced flush operation. I'd flush transients and prevented them from getting stored when rewrite rules were generated. Of course, this prevented the transients from storing the rewrite rules in the first place. So the whole thing wasn't there on the next page either. But that was with a buggy cache module.

That being said, I never fully understood why the rules were being flushed in the first place. #11384 probably had something to do with it, but not only.

[cisoprogressivo]

I patched functions.php and wp-config.php to get mod_rewrite counts, but I don't get any output if I go to www.mysite.com?test. If I use this code:

if ( isset($_GET['test']) ) {
 echo "<!-- Mod rewrite count ";
 echo get_option('check_mod_rewrite_counts');
 echo "-->";
}

I just get <!-- Mod rewrite count -->.
I also applied the patch in #11384, but it didn't help.

[Denis-de-Bernardy]

k... so that rules out the idea that it's being regenerated on every page load. Let's move on to 404 errors...

Can you try this patch here, in case it makes any difference?

​http://core.trac.wordpress.org/attachment/ticket/3426/3426.diff

[cisoprogressivo]

No it doesn't help.
I also tried downgrading my php to version 5.2.12 (from 5.3).

I tried a new account on my VPS and than installing a new WP 2.9.1 with a new database (but I used the same domain name so I get the same requests) and I have the same problem.

[nacin]

No patch or even identification of a WordPress problem. Moving to future for now, suggested close.

[MikeHansenMe]

No traction in 3 years, already had close keyword.