IIS 7 and Above
Intermittent 500 error with PHP 5.3.5
Last post Nov 06, 2012 01:50 PM by quichwrigley
Apr 23, 2012 07:23 AM|richardhauer2|LINK
Been running WordPress on PHP 5.3.5 for some time now but recently the system has developed a terminal problem. Every few loads I'll get a 500 error - maybe 6 to 10 page refreshes. There's no logging, no problems, and the page returns to normal on the
next refresh. Both my load balanced servers have the same problem on 2 WordPress separate sites each.
Machine is Windows 2008R2 (so IIS7.5).
I have tried for 10 hours to find the problem with no success.
Failed Request Tracing identifies: FastCgiModule / ExecuteRequestHandler / PHP53_via_FastCGI
The error code is: 0x00000000 (helpful)
I switched from using an Application Pool Identity to a named account, but no joy.
Occasionally I correlate the crash with the spawning of a new php-cgi.exe process, but not always. To make it crash I just sit on the home page and hit 'refresh' a few times - normally takes less than a minute to crash it.
When it works, it's very fast. Then every so often it'll just hang for about 20 seconds, then go bang. Then happily continue on its way. Nothing in "php-errors", nothing in the Event Log, nothing.
I can't recall any server changes and I'm hesitant to blame code since 4/5 page loads work properly. I tried installing a newer version of PHP (5.3.10) but that had no effect so, in the interests of science I rolled it back. I have two effectively identical
servers and I've only been playing with one so I have, in essence, a control group - not that it's helping.
I've read 1,000,000 posts on this topic and fettled 128.4 PHP.INI settings to no avail...
500 - Internal server error
Apr 23, 2012 08:38 AM|JanReilink|LINK
Apr 25, 2012 07:32 AM|richardhauer2|LINK
At present my settings are:
From the posts that I read the fastcgi.logging controls whether 'informational' messages are sent from the CGI'd process back through the FastCGI layer, which it incorrectly interperets as an error. Not sure how accurate my understanding is there - that
seems a bit lame. Why wouldn't you just check the result code? Anyways...
The other settings, I believe, are consistent with the 'production' configuration. Though no logging is generated whatsoever.
I tried with your suggested settings (and also set display_startup_errors = on) but it has not changed the result, nor has it resulted in any logs being written anywhere.
[While I didn't follow that precise page's instructions I did follow some very similar. Thing is it has been working for AGES - more than a year!]
I noted that there are pending Windows Updates so I'm going to install them and bounce the machine and see if that helps any - definitely clutching at straws now. :(
**EDIT I can now reproduce this issue on 2 machines, with 4 different customised WordPress installs, and one completely vanilla WordPress install simply by refreshing teh home page of the respective site repeatedly a dozen times or so.
Still waiting for the updates to complete. Then will update PHP also. Can't update WordPress itself but I'm highly sceptical that WordPress is at fault here.
**EDIT2 WordPress, as a potential culprit, is back on the table. I took the simple session counting script from the Install Link you provided and created a test.php on the site, then successfully refreshed it 500 times without crashing FastCGI or w3wp or
getting a 500 error back. I'm using WordPress 3.0.1 but I'm surprised that even vanilla against the default dummy post it crashes out. I'm not a PHP programmer so I can't do the script but my next stop would be a simple MySQL call to see if MySQL is involved
somehow. Any help there?
Apr 25, 2012 12:40 PM|richardhauer2|LINK
Just in case someone's following along. I fixed it. Whew.
Turns out the connections to MySql were timing out intermittently because ports on the DB server were all stuck in TIME_WAIT due to an unrelated Windows bug. I noticed that a pure PHP page ran just fine, but once i added a really simple 1-row DB call it
was crashing out. That exonerated WordPress again but put the blame squarely at MySql's feet. Much poking on the DB server and I noticed there was 45,000+ network connections in TIME_WAIT so I started closing firewall ports and they never went away... are
we starting to see a problem now?
Had to fettle the registry to fix that but it explains the intermittent works/doesn't work thing nicely.
Still can't believe there was no error message anywhere to say "Database connection timed out". That's painful. I'm just going to wire WordPress to MSSQL next time.
May 03, 2012 10:38 AM|robsiii|LINK
Nov 06, 2012 01:50 PM|quichwrigley|LINK
What did you do in your registry to fix this problem? I get this error occasionally, but usually when I try to edit the permalinks page in wordpress.