Apache运行HTML报500错误,apache-2.2 – 间歇性地发生FastCGI和Apache 500错误

概要

我观察到Apache的行为非常相似;看来这个问题并不是针对lighttpd的.

在我的情况下,症状完全相同; Apache访问日志中充斥着间歇性的500响应代码,并且PHP的错误日志中没有相应的条目(并且PHP错误报告被配置为最大冗长).

我在Apache邮件列表上广泛描述了这个问题(在列表档案中搜索主题“access.log中的间歇500响应,而没有error.log中的相应条目”).

根本原因

1100110的答案暗示了根本原因,但我将直接从Apache提供其他文档,以及消除问题的建议.

以下是Apache关于此问题的官方消息：

Special PHP considerations

By default, PHP FastCGI processes exit after handling 500 requests,

and they may exit after this module has already connected to the

application and sent the next request. When that occurs, an error will

be logged and 500 Internal Server Error will be returned to the

client. This PHP behavior can be disabled by setting

PHP_FCGI_MAX_REQUESTS to 0, but that can be a problem if the PHP

application leaks resources. Alternatively, PHP_FCGI_MAX_REQUESTS can

be set to a much higher value than the default to reduce the frequency

of this problem. FcgidMaxRequestsPerProcess can be set to a value less

than or equal to PHP_FCGI_MAX_REQUESTS to resolve the problem.

PHP child process management (PHP_FCGI_CHILDREN) should always be

disabled with mod_fcgid, which will only route one request at a time

to application processes it has spawned; thus, any child processes

created by PHP will not be used effectively. (Additionally, the PHP

child processes may not be terminated properly.) By default, and with

the environment variable setting PHP_FCGI_CHILDREN=0, PHP child

process management is disabled.

The popular APC opcode cache for PHP cannot share a cache between PHP

FastCGI processes unless PHP manages the child processes. Thus, the

effectiveness of the cache is limited with mod_fcgid; concurrent PHP

requests will use different opcode caches.

我们有它.

可能的解决方案

选项1

一种解决方案是将PHP_FCGI_MAX_REQUESTS设置为零,但采取此措施会导致内存泄漏失控的可能性.

我所咨询的各种文档都没有说清楚PHP通过Fast-CGI是否存在固有的内存泄漏(因此这种内置的“进程回收”行为)或风险是否仅限于写得不好,“失控的“脚本.

在任何情况下,将PHP_FCGI_MAX_REQUESTS设置为零都存在固有风险,尤其是在共享托管环境中.

选项2

如以上摘录中所述,第二解决方案是将FcgidMaxRequestsPerProcess设置为小于或等于PHP_FCGI_MAX_REQUESTS的值.但是,文档省略了一个重要的观点：该值也必须大于零(因为在这种情况下,零表示“无限制”或“禁用检查”).假定FcgidMaxRequestsPerProcess的默认值为零,并且PHP_FCGI_MAX_REQUESTS的默认值为500,则任何未覆盖这些值的管理员都将遇到间歇性500响应代码.出于这个原因,我无法理解为什么FcgidMaxRequestsPerProcess和PHP_FCGI_MAX_REQUESTS不共享相同的默认值.也许这是因为配置这两个指令会产生与将PHP_FCGI_MAX_REQUESTS设置为零相同的净结果;在这方面,文件含糊不清.

选项3

第三种解决方案是完全放弃Fast-CGI,转而采用类似的替代方案,例如suPHP或普通的CGI SuExec.我已经在各种PHP模式下执行了一些基本的原始性能基准测试,我的发现如下：

> Mod-PHP 77.7

> CGI 69.0

> suPHP 67.0

> Fast-CGI 55.7

Mod-PHP是性能最高的,得分为77.7.分数是任意的,仅用于演示PHP模式中页面加载时间的相对差异.

如果我们假设这些基准测试具有相当的代表性,那么由于其实施中存在一个(相当严重的)缺陷,因此似乎很少有理由坚持使用Fast-CGI.想到的唯一重要原因是操作码缓存.我的理解是PHP不能通过CGI或suPHP模式使用操作码缓存(因为进程不会跨请求持续存在).

虽然Fast-CGI没有利用操作码缓存(例如,通过APC)开箱即用,但聪明的用户设计了一种使用Fast-CGI(通过每用户缓存)使APC有效的方法：http://www.brandonturner.net/blog/2009/07/fastcgi_with_php_opcode_cache/ .但是有几个缺点：

>内存(RAM)要求相当可观,因为每个用户都有专用的缓存. (对于透视图,请考虑在Mod-PHP模式下,所有用户共享一个缓存.)

> Apache必须使用较旧的模块mod_fastcgi,而不是较新的等价物mod_fcgid. (有关详细信息,请参阅上一段中引用的文章.)

>配置相当复杂.

作为相关的推论,您在问题中说了以下内容：

First I am using APC so PHP is in control of it’s own processes, not FastCGI.

除非你使用mod_fastcgi(而不是mod_fcgid),除非你按照上面几段引用的步骤进行操作,否则APC会消耗资源而不会产生影响.因此,您可能希望禁用APC.

解决方案摘要

采取以下三种措施之一：

>将PHP_FCGI_MAX_REQUESTS环境变量设置为零. (在PHP脚本中引入内存泄漏的可能性使其失去控制.)>将FcgidMaxRequestsPerProcess设置为小于或等于PHP_FCGI_MAX_REQUESTS但大于零的值.> Abandon Fast-CGI支持类似的替代方案,例如suPHP或普通的CGI SuExec.