locked
Intermittent 500 error with PHP 5.3.5 RRS feed

  • Question

  • User-505261951 posted

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

    Help.

    Monday, April 23, 2012 7:23 AM

Answers

  • User-505261951 posted

    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.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, April 25, 2012 12:40 PM

All replies

  • User1994556403 posted
    It sounds like a bug in the FastCGI-error handler. What are your php.ini settings for display_errors, log_errors and fastcgi.logging? Try chaning the following php.ini settings display_errors (to On), log_errors (to Off) and fastcgi.logging (to 0). Assuming you've followed an installation and configuration guide like http://learn.iis.net/page.aspx/724/install-and-configure-php/. If you configure an user_ini.filename, you can overrule these settings on a per-directory basis. See php.ini comments for more information about this. Let me know if this solved your problem.
    Monday, April 23, 2012 8:38 AM
  • User-505261951 posted

    At present my settings are:

    • display_errors - Off
    • log_errors - On
    • fastcgi.logging - 0

    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?

    Wednesday, April 25, 2012 7:32 AM
  • User-505261951 posted

    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.

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, April 25, 2012 12:40 PM
  • User636028410 posted
    I'm seeing exactly the same thing -- TIME_WAITs on the MySQL ports and all. What did you do in the registry to make MySQL happy. Have you test MSSQL with WordPress multisite? I found it to be a little flakey, but that was about year ago.
    Thursday, May 3, 2012 10:38 AM
  • User1117110827 posted

    Hi Richard,

     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.

     Thanks,

    Rich

    Tuesday, November 6, 2012 1:50 PM