运行带有 lighttpd、php5、xcache 和 fastcgi 的 debian 系统。2GB RAM，2 核，5 分钟内平均峰值时间 CPU 负载低于 10%，使用不到 1GB 的 RAM。
该系统运行一个自定义构建的 Web 应用程序，用于抓取航班搜索网站的数据，不允许缓存（结果），因此它是实时生成的，执行此操作的代码使用 libcurl，每次搜索可能都要执行几秒钟。还有一个 OpenX 广告系统。
最近，该网站似乎会间歇性地超时，我创建了一个简单的测试脚本，它只打印一个单词以确保它与 MySQL 数据库无关。
据我所知，当我们运行操作码缓存器时，我们不应该运行许多 fastcgi“max-procs”（因为我认为每个进程都会使用自己的缓存），而是增加子进程。
子进程从 20（2 个 max-procs）增加到 32，没有明显的区别。据我所知，同时运行的脚本数量是 max-procs * children。查看输出状态.统计信息-url虽然脚本需要很长时间才能运行，但似乎并不表明所有孩子都很忙。
正确的方法是不断增加 fastcgi 的子节点，还是还有什么其他方法？是否可以查看哪些脚本正在运行、它们运行了多长时间等等？
fastcgi.active-requests：39
fastcgi.backend.0.0.connected：2259
fastcgi.backend.0.0.died：0
fastcgi.backend.0.0.disabled：0 fastcgi.backend.0.0.load
：19
fastcgi.backend.0.0.overloaded：0
fastcgi.backend.0.1.connected：4646
fastcgi.backend.0.1.died：0 fastcgi.backend.0.1.disabled
：0
fastcgi.backend.0.1.load：20
fastcgi.backend.0.1.overloaded：0
fastcgi.backend.0.load：39
fastcgi.requests：6905
10-fastcgi.conf：
“max-procs”=> 2，
“空闲超时”=> 20，
“bin-environment”=>（
“PHP_FCGI_CHILDREN”=>“32”，
“PHP_FCGI_MAX_REQUESTS”=>“500”
lighttpd 错误日志，包含以下内容：
2011-05-30 09:45:48: (server.c.1258) 注意：在写入 15180 字节后，对 /index.php?//search/poll 的请求超时。我们等待了 360 秒。如果这是个问题，请增加 server.max-write-idle
2011-05-30 09:49:08: (server.c.1258) 注意：在写入 12420 字节后，对 /index.php?// 的请求超时。我们等待了 360 秒。如果这是个问题，请增加 server.max-write-idle
答案1
将您的 PHP 二进制文件更改为纤维增强塑料而不是旧的 fastcgi。
FPM（FastCGI 进程管理器）是另一种 PHP FastCGI 实现，它具有一些附加功能（大多数情况下），对于负载过重的站点很有用。
运行更加稳定，您不应该遇到超时问题。
答案2
就像 vartec 所说的那样，PHP-FPM 可能是一个好主意。请注意，PHP 5.2 版本不支持动态进程生成（尽管它是一个可配置选项），因此您必须确保拥有足够的工作程序来处理所有流量高峰。
如果您切换到 PHP-FPM，一个好处就是操作码缓存可以在所有 PHP 进程之间共享（这可以通过 lighttpd 方法实现，但有点烦人）。
您每秒看到的请求数是多少？我通常会尝试为服务器看到的每个请求/秒运行一个 PHP 进程。在内存相对较少的系统上，这可能不是最好的主意，但我还没有遇到任何问题。
您使用 unix 套接字还是 TCPIP 连接 lighttpd 和 php？如果您使用 TCPIP，您绝对应该切换到 unix 套接字。我见过使用 TCPIP 时出现的各种间歇性、难以诊断的问题。您可能遇到了 TCPIP 的防火墙限制或连接限制。
您是否使用 Munin 之类的工具进行监控？拥有流量负载、服务器负载、mysql 负载等图表可能会对您很方便。虽然仅拥有这些图表并不能解决您的问题，但它们对您来说非常方便。
答案3
其中一个供应商在响应查询时出现问题，因此网站上的所有搜索都排队等待由 fastcgi 执行的大量线程。似乎在 fastcgi 方面没有真正的修复，而是在代码中实现适当的超时并可能检测供应商何时没有响应 - 并停止在那里发送更多查询。
另外，我已切换到 php-fpm 并正在持续监控“/status”，以便尽早发现此类问题。