我们有七个使用IIS编写的运行在Windows 2008服务器上的PHP网站。 他们现在都很慢。
当我查看任务pipe理器时，我看到大约10个php-cgi.exe进程，他们都占用了CPU的0％，除了一个占25％。 这是一个四核服务器，所以它是100％的一个核心。
如果我观察几秒钟，25％的过程将会变为0％，另一个不同的php-cgi.exe过程将跳到25％。 所以所有的php-cgi.exe进程只是排队等待一个核心，每个进程使用100％的处理器。
这7个站点中的每一个都位于IIS的自己的应用程序池中，我们正在使用FastCGI。 PHP版本是5.3。
有任何想法吗？ 谢谢！
编辑：这是我们的FastCGI设置：
<fastCgi> <application fullPath="C:\Program Files (x86)\PHP\v5.3\php-cgi.exe" monitorChangesTo="C:\Program Files (x86)\PHP\v5.3\php.ini" activityTimeout="600" requestTimeout="600" instanceMaxRequests="10000"> <environmentVariables> <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" /> <environmentVariable name="PHPRC" value="C:\Program Files (x86)\PHP\v5.3" /> </environmentVariables> </application> </fastCgi> 编辑＃2：我们部分想出来。 由于权限问题，PHP从来没有垃圾收集会话，所以有数百万个会话文件。
但是我仍然想知道为什么它只使用一个核心。 现在网站要快得多，但我们还没有解决。 有人知道吗？
这个问题最终导致在PHP保存会话文件（sess_ ）的文件夹中权限错误。 垃圾收集从我们部署这个服务器或者它有一段时间以来从来没有工作过，但是我们改变了App Pool的身份，或者是新的身份没有权限删除文件。 无论如何，我们有超过200万的临时文件夹中的sess_文件。 花了几个小时，但最后一个“del / F / Q sess_ ”命令完成了，我们重新启动了这个站点，并且再次很好（从平均60秒的页面加载时间到不到1秒）。 我不知道这是否修复了“所有组合的cgi-php.exe进程永远不会使用多个核心组合”的问题，但对我来说，在Windows的Windows实现中创build这些sess_文件也可能被devise成导致这种现象的一种方式（例如，如果是单套房线程的话）。
无论如何，这个故事的寓意是，如果你看到CPU消耗非常缓慢而稳定的增长（也许在单个核心的100％水平上）并且http响应时间也缓慢增加，那么检查你存储你的文件夹PHP会话文件（sess_ *），看看是否Windows资源pipe理器崩溃，当你打开该文件夹！ 🙂
（顺便说一下，这是W2K8（不是R2），所以我认为它是IIS 7不是7.5）