What's the downside of limiting the number of php-cgi.exe *32 processes with maxinstances? RRS feed

  • Question

  • User-240342396 posted

    <div class="post-text" itemprop="description">

    We have a busy website that hangs periodically when running a popular open source php program. When hanging (inaccessible 500 error) the cpu and ram look fine on the server, the only odd thing is the 200 or so php-cgi.exe *32 processes that are running, usually we have about 16.

    When I RESET IIS the problem goes away and the number of php processes becomes normal.

    The IIS maxInstances setting is 0 at the moment, which lets Windows dynamically adjust the value. Some forums have suggested setting it to 10 X #cpu (ie 40 for us) but don't seem to have much reasoning to back up the limiting value.

    Whats the downside of limiting the number of php processes, will users be restricted from viewing webpages when that limit is reached? I'ld like to stop my website from hanging or getting 500 error messages but not at the cost of making it inaccessible to some.

    Am i managing exisiting php processes incorrectly, should they be recycled or terminated more frequently if not doing anything? (when I load a single page 6 php processes can be spawned and linger for awhile even though they dont appear to be doing anything)

    UPDATE: reviewed Zabbix logs during the a recent outage, it shows number of threads and processes increasing every 10 minutes, then decreasing every 10 minutes, presumably due to activity timeout & request timeout being set to 600 seconds. Memory and cpu looked fine at this time. Should I reduce my Activity Timeout value, I think it kills processes that are hung?

    IIS 7.5
    php 5.3.16
    14gb Memory
    4 cpu
    Windows 2008 R2 64-bit
    Zend Extension Build API220090626, NTS, VC9
    PHP Extension Build API20090626, NTS, VC9
    Thread Safety disabled


    Tuesday, October 8, 2013 12:32 PM

All replies

  • User1183424175 posted


    Ensure that FastCGI always recycles the php-cgi.exe processes before the native PHP recycling kicks in. The FastCGI process recycling behavior is controlled by the configuration property instanceMaxRequests.

    For more information, you can refer here about Using FastCGI to Host PHP Applications on IIS 7


    And please refer the document about Tuning Windows Server 2008 for PHP


    Hope it can hlep you.

    Wednesday, October 9, 2013 7:34 AM
  • User-240342396 posted

    I've already set instance maxrequests and PHP_FCGI_MAX_REQUESTS to 10000 to ensure proper recycing behavior.
    The article above does not indicate maxinstances of 0 as the default, is that a difference between IIS 7 and IIS 7.5 (my environment), is it better to let windows 2008 manage it dynamically in IIS7.5 or should I change the default of 0 to something like 40 (seeing as our ram and cpu are typically fine)?

    Here's my other fast-cgi settings in case that helps:

    instance maxrequests 10000
    max instances 0
    activity timeout 600
    idle timeout 300
    queue length 1000
    rapid fails perminuyte 10
    request timeout 600


    Tuesday, October 15, 2013 9:46 AM