Make WordPress Core

Opened 13 years ago

Closed 10 years ago

Last modified 21 months ago

#11843 closed defect (bug) (invalid)

htaccess pointing to wordpress makes CPU overload

Reported by: cisoprogressivo's profile cisoprogressivo Owned by: ryan's profile ryan
Milestone: Priority: normal
Severity: normal Version: 2.9.1
Component: Rewrite Rules Keywords:
Focuses: Cc:


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]

Also my hosting is investigatin without results.
Other people seems to have this problem in past:

Attachments (2)

before.png (113.4 KB) - added by cisoprogressivo 13 years ago.
after.png (106.2 KB) - added by cisoprogressivo 13 years ago.

Download all attachments as: .zip

Change History (23)

#1 @miqrogroove
13 years ago

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

#2 @cisoprogressivo
13 years ago


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

#3 @cisoprogressivo
13 years ago

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".

#4 @miqrogroove
13 years ago

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

#5 @cisoprogressivo
13 years ago

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.

#6 @Denis-de-Bernardy
13 years ago

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

#7 @cisoprogressivo
13 years ago

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.

#8 @cisoprogressivo
13 years ago

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.

#9 @cisoprogressivo
13 years ago

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.

#10 @Denis-de-Bernardy
13 years ago

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') ) {
			$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;


			$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

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

#11 @dd32
13 years ago

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..

#12 @Denis-de-Bernardy
13 years ago

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.

#13 follow-up: @dd32
13 years ago

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..

#14 in reply to: ↑ 13 @Denis-de-Bernardy
13 years ago

  • Component changed from General to Rewrite Rules
  • Milestone changed from Unassigned to 3.0
  • Owner set to ryan

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.

#15 @sirzooro
13 years ago

  • Cc sirzooro added

#16 @cisoprogressivo
13 years ago

I patched functions.php and wp-config.php to get mod_rewrite counts, but I don't get any output if I go to 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.

#17 @Denis-de-Bernardy
13 years ago

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?

#18 @cisoprogressivo
13 years ago

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.

#19 @nacin
13 years ago

  • Keywords close added; htaccess premalink removed
  • Milestone changed from 3.0 to Future Release

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

#20 @MikeHansenMe
10 years ago

  • Cc mdhansen@… added
  • Resolution set to invalid
  • Status changed from new to closed

No traction in 3 years, already had close keyword.

#21 @helen
10 years ago

  • Keywords close removed
  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.