nginx + php-fpm:上游超时

build立:

我有一个运行nginx + php-fpm的虚拟盒子(vagrant)。 我已经加载了xdebug模块。 版本:

OS:

uname -a Linux vagrant-ubuntu-vivid-64 3.19.0-26-generic #28-Ubuntu SMP Tue Aug 11 14:16:32 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux 

PHP5-FPM:

 php5-fpm -v PHP 5.6.4-4ubuntu6.2 (fpm-fcgi) (built: Jul 2 2015 15:59:03) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies with Xdebug v2.2.6, Copyright (c) 2002-2014, by Derick Rethans 

nginx的:

 nginx -V nginx version: nginx/1.6.2 (Ubuntu) TLS SNI support enabled 

问题:

由于我不明原因,我得到:

 upstream timed out (110: Connection timed out) while reading response header from upstream 

我尝试了两个unix套接字设置为php5-fpm和TCP设置 – 都失败了相同的错误。

随着套接字的设置 ,我试图改变听写权限,甚至到777 – 没有什么区别。 以防万一,套接字的configuration( www.conf )的样本:

 listen.owner = www-data listen.group = www-data listen.mode = 0666 

和用户存在:

 id www-data uid=33(www-data) gid=33(www-data) groups=33(www-data) 

但是, 使用TCP设置 ,我有:

 $ telnet 127.0.0.1 9000 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. 

这意味着它确实在那个港口上聆听。 另外,另一个检查:

 netstat -tulpn | grep 9000 tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 4396/php-fpm.conf) 

我试图禁用xdebug也只是为了确保它不是连接问题(但事实上,这是没有意义的,因为我的IDE在主机上启动,因此它的端口与VM内的端口无关) 。

我试图将fastcgi_read_timeoutmax_execution_time一起设置为非常高的值(几千秒),这也没有帮助的情况下。

那么可能会导致这种行为,以及如何解决这个问题呢? 或者至less,我能做些什么来debugging呢?

更新:

当我设置一个非常高的超时时间,服务器响应。 但事情是 – 我看到不是一个应用程序的问题,因为:

  • 应用程序基本上只是将消息写入日志文件
  • 请求“挂起”不知名的原因为分钟, 之后出现在nginx的访问日志和应用程序日志中(所以,当应用程序日志出现在nginx日志中时立即请求)

有了以上的东西,我现在很迷茫:nginx告诉网关有超时。 这意味着:请求来到nginx,然后在nginx和它的后端之间超时(所以,在这种情况下,php5-fpm)。 如果请求“挂起”甚至出现在nginx日志之前 – 后端如何负责? 我的意思是,为什么nginx有“上游超时”?

因此,问题将是 – 什么会导致这样的延误?

如果有任何需要的附加信息 – 我会提供。

我也在SO / SF上试过类似的问题,但是并没有帮助

问题解决了。 问题在于stream浪的设置:

 # Shared folder config.vm.synced_folder "./../", "/vagrant/", :nfs => true 

而且,由于应用程序试图将日志写入共享文件夹,因为logging器的实现尝试通过flock()应用locking,所以在NFS的情况下无法正常工作。

所以解决方法是:

  • 挂载共享文件夹不是NFS设备
  • 或者不要使用文件locking。 虽然这个选项似乎是“更容易”的方式来解决这个问题 – 它有不利的一面,因为如果你的应用程序使用供应商预定义的包(通过composer php作为例子),很难甚至意识到如果应用程序正在使用的东西可能会失败像这种情况