nginx + php-fpm: tempo limite upstream

Question

Configuração:

Eu tenho uma caixa virtual (vagrant) rodando nginx + php-fpm dentro. Eu tenho o módulo xdebug carregado. Versões:

SO:

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

Problema:

Pela razão desconhecida que estou recebendo:

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

Eu tentei a configuração de dois soquetes unix para php5-fpm e configuração TCP - ambos falharam com o mesmo erro.

Com a configuração dos sockets , tentei alterar as permissões de escuta para leitura / gravação e até mesmo para 777 - nenhuma diferença. Apenas no caso, amostra de configuração ( www.conf ) para sockets:

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

E o usuário existe:

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

Com a configuração TCP , no entanto, tenho:

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

Significa que, de fato, está escutando nessa porta. Além disso, outro cheque:

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

Eu tentei desabilitar o xdebug também - só para ter certeza de que não há um problema com a conexão chegar lá (mas, na verdade, é inútil, pois meu IDE é lançado na máquina host e, portanto, sua porta não tem nada a ver com porta dentro da VM).

Eu tentei definir fastcgi_read_timeout junto com max_execution_time para valores realmente altos (milhares de segundos) e isso também não está ajudando no caso.

Então, o que poderia causar esse comportamento e como resolver o caso? Ou, pelo menos, o que posso fazer para depurar o caso?

Atualização:

Quando defino um tempo limite muito alto, o servidor responde. Mas a coisa é - que eu vejo não é um problema de aplicação desde:

• Aplicativo basicamente apenas grava mensagem no arquivo de log
• A solicitação "trava" por motivos desconhecidos por minutos e após que aparece no log de acesso nginx junto com o log do aplicativo (assim, os logs do aplicativo são solicitados imediatamente quando aparecem no log nginx)

Com as coisas acima, agora estou bastante perdido: o nginx informa que gateway tem tempo limite. O que deve significar: o pedido veio para o nginx e foi excedido no tempo entre o nginx e o back-end (portanto, php5-fpm neste caso). Se o pedido "trava" antes mesmo de aparecer nos logs do nginx - como o backend é responsável? Quero dizer, por que nginx tem "timeout upstream"?

Portanto, a questão será: o que pode causar esses atrasos?

_{Se houver alguma informação adicional que seja necessária - eu a fornecerei.}

_{Eu também tentei perguntas semelhantes sobre o SO / SF e isso não ajudou o caso}

    

Answer 1

Problema resolvido. O problema está na configuração do vagrant:

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

E como o aplicativo estava tentando gravar o log na pasta compartilhada, ele ficou preso porque a implementação do criador de logs estava tentando aplicar bloqueio no arquivo por meio de flock() que simplesmente não funciona corretamente no caso do NFS.

Então, a solução é:

• Monte as pastas compartilhadas não como dispositivos NFS
• Ou não use bloqueios de arquivos. Embora essa opção pareça ser a maneira "mais fácil" de resolver o problema, ela tem desvantagem, pois, se o seu aplicativo estiver usando pacotes pré-definidos pelo fornecedor (via composer como exemplo), é difícil perceber se o aplicativo está usando algo que pode falhar como neste caso.