I think I may have found a solution or at least a work round to this problem, at least it seems to be working for me reliably.
Try setting the Max Instances setting, under IIS Server --> FastCGI Settings, to 1.
It seemed to me that only certain requests were causing a php-cgi.exe process to go rogue and hog the cpu, usually when updating a post. When reading other posts on this issue one of them mentioned the Max Instances setting and that it is set to default at 0 or automatic. I wondered if this might not have a good effect when things aren't as they should be. I'm guessing (but this isn't quite my field of expertise) if a certain request(s) is causing the process to lock-up, so FastCGI just creates another, whilst leaving the first in place. Somehow it seems only having a single instance allows PHP to move on from the lock-up and the cpu stays under control.
For servers with high-levels of requests setting FastCGI to only a single instance may not be ideal, but it certainly beats the delays I was getting before. Used in combination with WP-SuperCache and WinCache, things seem to nipping along nicely now.
checked and found that multiple php-cgi.exe was running under default apppool and it consumed 95% cpu load
IIS reset /app pool reset didn't helped .. Hence , reviewed Common Gateway Interface settings and found the value as "0", which could allow the multiple instances to run .
From process explorer i saw mutiple instances were running and that consumed 95% cpu load . Changed the Common Gateway Interface settings from "0" to "1" and the CPU load is drastically down.
########
Also , ESX box load went down now. Resolving this case now
##################
Also -- try this - http://serverfault.com/questions/373024/php-processes-run-one-at-a-time-always-taking-100-of-one-core
Overview
The FastCGI <application> element contains the configurations settings for a specific FastCGI process pool definition. When FastCGI is used, IIS will use the value in the maxInstances attribute of the <application> element to determine the number of FastCGI processes that can run in the process pool.
The simplest FastCGI application pool definition requires that you include the fullPath attribute in an <application> element to define the binaries to use for the specific application framework. For the PHP framework, set the fullPath attribute to the directory and file name of the PHP binaries.
Other attributes are optional and let you configure a number of other parameters. These include the maximum number of requests that a FastCGI worker process can process before it is recycled, the maximum number of worker processes for an application pool, and the maximum amount of time a FastCGI request can take.
Note: In order to process requests by using FastCGI, you must first map the path and the specific file name extensions to the FastCGI module and specify the target FastCGI process as the script processor.
New in IIS 7.5
IIS 7.5 added the following attributes to the <fastCgi>/<application> element:
The monitorChangesTo attribute lets you specify a file to monitor for changes that might affect the behavior of a FastCGI application. For example, if you use the PHP framework, you can configure IIS to monitor the PHP.INI file for changes by specifying the full path to the file in the monitorChangesTo attribute.
The stderrMode attribute specifies how IIS 7 will handle errors that are returned from a FastCGI application through the STDERR stream.
The signalBeforeTerminateSeconds attribute lets you configure IIS to wait for a specified period of time after IIS signals a FastCGI application that it needs to shut down. This lets a FastCGI application clean up any settings before IIS terminates the process.
Compatibility
Version Notes
IIS 8.5 The <application> element was not modified in IIS 8.5.
IIS 8.0 The default value of the maxInstances attribute was changed from 4 to 0 in IIS 8.0.
IIS 7.5 The <application> element of the <fastCgi> collection was updated in IIS 7.5 with the monitorChangesTo, stderrMode, and signalBeforeTerminateSeconds attributes.
IIS 7.0 The <application> element of the <fastCgi> collection was introduced in IIS 7.0.
IIS 6.0 N/A
Try setting the Max Instances setting, under IIS Server --> FastCGI Settings, to 1.
It seemed to me that only certain requests were causing a php-cgi.exe process to go rogue and hog the cpu, usually when updating a post. When reading other posts on this issue one of them mentioned the Max Instances setting and that it is set to default at 0 or automatic. I wondered if this might not have a good effect when things aren't as they should be. I'm guessing (but this isn't quite my field of expertise) if a certain request(s) is causing the process to lock-up, so FastCGI just creates another, whilst leaving the first in place. Somehow it seems only having a single instance allows PHP to move on from the lock-up and the cpu stays under control.
For servers with high-levels of requests setting FastCGI to only a single instance may not be ideal, but it certainly beats the delays I was getting before. Used in combination with WP-SuperCache and WinCache, things seem to nipping along nicely now.
checked and found that multiple php-cgi.exe was running under default apppool and it consumed 95% cpu load
IIS reset /app pool reset didn't helped .. Hence , reviewed Common Gateway Interface settings and found the value as "0", which could allow the multiple instances to run .
From process explorer i saw mutiple instances were running and that consumed 95% cpu load . Changed the Common Gateway Interface settings from "0" to "1" and the CPU load is drastically down.
########
Also , ESX box load went down now. Resolving this case now
##################
Also -- try this - http://serverfault.com/questions/373024/php-processes-run-one-at-a-time-always-taking-100-of-one-core
The FastCGI <application> element contains the configurations settings for a specific FastCGI process pool definition. When FastCGI is used, IIS will use the value in the maxInstances attribute of the <application> element to determine the number of FastCGI processes that can run in the process pool.
The simplest FastCGI application pool definition requires that you include the fullPath attribute in an <application> element to define the binaries to use for the specific application framework. For the PHP framework, set the fullPath attribute to the directory and file name of the PHP binaries.
Other attributes are optional and let you configure a number of other parameters. These include the maximum number of requests that a FastCGI worker process can process before it is recycled, the maximum number of worker processes for an application pool, and the maximum amount of time a FastCGI request can take.
Note: In order to process requests by using FastCGI, you must first map the path and the specific file name extensions to the FastCGI module and specify the target FastCGI process as the script processor.
New in IIS 7.5
IIS 7.5 added the following attributes to the <fastCgi>/<application> element:
The monitorChangesTo attribute lets you specify a file to monitor for changes that might affect the behavior of a FastCGI application. For example, if you use the PHP framework, you can configure IIS to monitor the PHP.INI file for changes by specifying the full path to the file in the monitorChangesTo attribute.
The stderrMode attribute specifies how IIS 7 will handle errors that are returned from a FastCGI application through the STDERR stream.
The signalBeforeTerminateSeconds attribute lets you configure IIS to wait for a specified period of time after IIS signals a FastCGI application that it needs to shut down. This lets a FastCGI application clean up any settings before IIS terminates the process.
Compatibility
Version Notes
IIS 8.5 The <application> element was not modified in IIS 8.5.
IIS 8.0 The default value of the maxInstances attribute was changed from 4 to 0 in IIS 8.0.
IIS 7.5 The <application> element of the <fastCgi> collection was updated in IIS 7.5 with the monitorChangesTo, stderrMode, and signalBeforeTerminateSeconds attributes.
IIS 7.0 The <application> element of the <fastCgi> collection was introduced in IIS 7.0.
IIS 6.0 N/A
No comments:
Post a Comment