我有一台服务器工作正常,直到2013年10月3日上午10点50分,当它开始间歇地返回“502坏门户”错误到客户端。
5个浏览器请求中大约有4个成功,但是大约有5个失败,502个。
nginx错误日志包含数百个这些错误;
2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"
但是,PHP错误日志不包含任何匹配的错误。
有没有办法让PHP给我更多关于为什么重置连接的信息?
这是nginx.conf
;
user www-data; worker_processes 4; error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; access_log /var/log/nginx/access.log; sendfile on; keepalive_timeout 30; tcp_nodelay on; client_max_body_size 100m; gzip on; gzip_types text/plain application/xml text/javascript application/x-javascript text/css; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; include /gvol/sites/*/nginx.conf; }
这是这个网站的.conf
。
server { server_name www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home; root /gvol/sites/bec/www/; index index.php index.html; location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 2592000; # 30 days log_not_found off; } ## Trigger client to download instead of display '.xml' files. location ~ \.xml$ { add_header Content-disposition "attachment; filename=$1"; } location ~ \.php$ { fastcgi_read_timeout 3600; include /etc/nginx/fastcgi_params; keepalive_timeout 0; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; } } ## bec-components.co.uk ## server { server_name bec-components.co.uk; rewrite ^/(.*) http://www.bec-components.co.uk$1 permanent; }
我一直相信,如果我的networking服务器告诉我: 502 Bad Gateway
这是什么意思:
你的fastcgi进程不能被nginx访问; 要么减慢,要么根本不对应。 坏的网关意味着:nginx不能将fastcgi_pass定义为资源127.0.0.1:9000; 在那个特定的时刻 。
你的初始错误日志告诉了这一切:
。
recv() failed -> nginx failed (104: Connection reset by peer) while reading response header from upstream, -> no complete answer, or no answer at all upstream: "fastcgi://127.0.0.1:9000", -> who is he, who failed???
从我有限的pov我会build议:
我知道这个话题已经老了,但偶尔也会popup来,所以在网上寻找答案,我提出了以下三种可能:
session.save_path = "/var/lib/php/sessions"
)。 这可能是不好的权限,坏的所有权,不良的用户/组,或者更多的深奥/晦涩的问题,如在该目录(甚至一个完整的磁盘! 这通常不会在PHP错误日志中留下许多核心转储,甚至可能没有。 保持得到这个。 如果使用它(通过replaceAPC),则通过增加opcache
内存限制来解决这个问题。 似乎PHP-FPM在caching过满时断开连接。 这也是shgnInc的答案在短时间内解决这个问题的原因。
所以find文件/etc/php5/fpm/php.ini
(或者你的发行版中的等价物)并且增加memory_consumption
到你的网站需要的任何级别。 禁用opcache
也可能工作。
[opcache] opcache.memory_consumption = 196
你可能想在github上考虑这个git: https : //gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209
我遇到了类似的情况,当我检查我的上游服务器的错误日志,他们报告了一些ulimit错误,所以我增加了1000000(在上游和nginx框),一切工作正常
在我的情况下,同样的问题,我只是重新启动php-fpm
服务,所以它解决了。
sudo service php5-fpm restart
或者有些时候这个问题是由于大量的请求而发生的。 默认情况下,php5-fpm中的pm.max_requests
可能是100或更低。
为了解决它的价值取决于你的网站的要求,例如500。
之后,你必须重新启动服务
在我的情况下,禁用xdebug扩展确实有帮助。