PHP-FPM - 在读取响应标头时上游过早关闭连接答案

【问题标题】：PHP-FPM - upstream prematurely closed connection while reading response headerPHP-FPM - 在读取响应标头时上游过早关闭连接
【发布时间】：2013-04-29 00:27:17
【问题描述】：

已经看到同样的问题 - upstream prematurely closed connection while reading response header from upstream, client 但正如 Jhilke Dai 所说，它根本没有解决，我同意。在安装 nginx+phpFPM 时遇到同样的错误。当前软件版本：FreeBSd9.1 上的 nginx 1.2.8 php 5.4.13 (cli)。实际上有点隔离了这个错误，并确定它是在尝试通过 phpMyadmin 将大于 3 mbs 的大文件导入 mysql 时发生的。当达到 30 秒限制时，还计算后端关闭连接。 Nginx 错误日志抛出这个

 [error] 49927#0: *196 upstream prematurely closed connection while reading response header from upstream, client: 7X.XX.X.6X, server: domain.com, request: "POST /php3/import.php HTTP/1.1", upstream: "fastcgi://unix:/tmp/php5-fpm.sock2:", host: "domain.com", referrer: "http://domain.com/phpmyadmin/db_import.php?db=testdb&server=1&token=9ee45779dd53c45b7300545dd3113fed"

我的 php.ini 限制相应提高

upload_max_filesize = 200M
default_socket_timeout = 60
max_execution_time = 600
max_input_time = 600

my.cnf 相关限制

max_allowed_packet = 512M

Fastcgi 限制

location ~ \.php$ {
# fastcgi_split_path_info ^(.+\.php)(.*)$;
fastcgi_pass unix:/tmp/php5-fpm.sock2;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;

fastcgi_intercept_errors on;
fastcgi_ignore_client_abort on;
fastcgi_connect_timeout 60s;
fastcgi_send_timeout 200s;
fastcgi_read_timeout 200s;
fastcgi_buffer_size 128k;
fastcgi_buffers 8 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;

尝试更改 fastcgi 超时以及缓冲区大小，但没有帮助。 php 错误日志没有显示问题，启用所有通知，警告 - 没有任何用处。还尝试禁用 APC - 没有效果。

【问题讨论】：

标签： nginx apc php

【解决方案1】：

我遇到了同样的问题，在我的开发机器（OSX + nginx + php-fpm）上经常随机出现502 Bad Gateway，并通过更改/usr/local/etc/php/5.6/php中的一些参数来解决它-fpm.conf：

我有这个设置：

 pm = dynamic
 pm.max_children = 10
 pm.start_servers = 3
 pm.max_spare_servers = 5

...并将它们更改为：

pm = dynamic
pm.max_children = 10
pm.start_servers = 10
pm.max_spare_servers = 10

...然后重启了php-fpm服务。

此设置基于我在此处找到的内容：[https://bugs.php.net/bug.php?id=63395]

【讨论】：

有效！我到处寻找解决方案，这是我发现唯一可行的解决方案。

【解决方案2】：

您的脚本计算需要多长时间？尝试在 PHP 和 Nginx 中设置巨大的超时并在请求期间监视您的系统。然后调整您的值以优化性能。

另外，降低 PHP-FPM 中的日志级别，也许有某种类型的警告、信息或调试跟踪可以为您提供一些信息。

最后，注意 PHP-FPM 中可用的子进程和进程的数量。也许 Nginx 饿死了，等待 PHP-FPM 子进程可用。

【讨论】：