nginx fecha a conexão em algumas fotos

8

Há um problema com nginx. Fecha a conexão antes que o cliente termine o download. Parece que:

 $ wget -O /dev/null http://www.site.com/images/theme/front/clean.jpg
--2012-07-11 21:37:03--  http://www.site.com/images/theme/front/clean.jpg
Resolving www.site.com (www.site.com)... 123.234.123.234
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90707 (89K) [image/jpeg]
Saving to: `/dev/null'

26% [===============>                    ] 24,291      --.-K/s   in 8.7s    

2012-07-11 21:37:12 (2.74 KB/s) - Connection closed at byte 24291. Retrying.

--2012-07-11 21:37:13--  (try: 2)  http://www.site.com/images/theme/front/clean.jpg
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 90707 (89K), 66416 (65K) remaining [image/jpeg]
Saving to: `/dev/null'

53% [+++++++++++++++============>        ] 48,555      --.-K/s   in 8.7s    

2012-07-11 21:37:23 (2.74 KB/s) - Connection closed at byte 48555. Retrying.

--2012-07-11 21:37:25--  (try: 3)  http://www.site.com/images/theme/front/clean.jpg
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 90707 (89K), 42152 (41K) remaining [image/jpeg]
Saving to: `/dev/null'

100%[+++++++++++++++++++++++++++========>] 90,707      --.-K/s   in 0.1s    

2012-07-11 21:37:25 (311 KB/s) - `/dev/null' saved [90707/90707]

ao mesmo tempo com imagens menores, tudo está bem:

 $ wget -O /dev/null http://www.site.com/images/theme/front/grease.jpg
--2012-07-11 21:41:28--  http://www.site.com/images/theme/front/grease.jpg
Resolving www.site.com (www.site.com)... 123.234.123.234
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 21404 (21K) [image/jpeg]
Saving to: `/dev/null'

100%[====================================>] 21,404      --.-K/s   in 0.07s   

2012-07-11 21:41:29 (316 KB/s) - `/dev/null' saved [21404/21404]

Esta é a razão pela qual esta imagem não pode ser totalmente desenhada no navegador. Eu posso ver apenas a cabeça disso.

O Nginx está configurado como front-end e apache como back-end. O link direto para o apache funciona bem, então há um problema no nginx. Estou certo?

configuração nginx:

user satellite;
worker_processes  1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    multi_accept on;
}

http {
    include       /etc/nginx/mime.types;
    access_log  /var/log/nginx/access.log;

    sendfile        on;
    keepalive_timeout  0;
    tcp_nodelay        on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    client_max_body_size 100m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
    server {
            listen 123.234.123.234:80;
            server_name site.com www.site.com;
            location ~* ^/(admin/|dump/|webmail/|myadmin/|webim/) {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_redirect http://site.com:8080/ /;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
            }
            location / {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_redirect http://site.com:8080/ /;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_cache ino;
                    proxy_cache_valid 12h;
                    proxy_hide_header "Set-Cookie";
                    proxy_ignore_headers "Cache-Control" "Expires";
            }
            location ~* ^.+\.(jpg|swf|flv|ico|txt|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
                    access_log /home/satellite/logs/site.com.nginx.access.log;
                    error_page 404 = @fallback;
                    if ( $host ~* ^((.*).site.com)$ ) {
                            set $proot /home/satellite/www/$1;
                            break;
                    }
                    if ( $host = "www.site.com" ) {
                            break;
                    }
                    if ( $host = "site.com" ) {
                            break;
                    }

                    root /home/satellite/www/site.com;
            }
            location @fallback {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
            }
    }

onde devo cavar para corrigir esse problema?

pressa
fonte
1
Você tentou desligar sendfile?
VBart 12/07/12
Sim, nada mudou.
apressar

Respostas:

9

A principal coisa que esqueci é verificar /var/log/nginx/error.log.

2012/07/12 08:46:44 [crit] 24074#0: *3 open() 
"/var/lib/nginx/proxy/1/00/0000000001" failed (13: Permission denied) 
while reading upstream, client: 109.173.96.30, server: site.com, request: 
"GET /images/theme/front/clean.jpg HTTP/1.1", upstream: 
"http://123.234.123.234:8080/images/theme/front/clean.jpg", 
host: "www.site.com", referrer: "http://www.google.com"

Então, eu fixei /var/lib/nginx/proxy/*permissões de diretórios ( sudo chown -R www-data:www-data /var/lib/nginx/proxy/*) e agora tudo funciona muito bem. Agradeço a todos pela ajuda.

pressa
fonte
Obrigado por isso. Parece um conselho óbvio, mas eu também não tinha verificado. No meu caso, a causa foi a seguinte: [crit] 6 # 6: * 2577 mkdir () "/ var / cache / nginx / proxy_temp / 8" falhou (28: não há espaço no dispositivo) durante a leitura upstream
Damian Moore
1

Uma possível razão para o fechamento da conexão é uma conexão lenta e uma curta keepalive_timeout. O valor padrão para o keepalive_timeouté 75s. Se for muito curto e a conexão estiver lenta, poderá ser fechada muito cedo.

http {
    ..
    keepalive_timeout 75;
}

Uma razão pela qual o download da sua imagem pode ser lento é o seu aplicativo. Se você estiver usando um aplicativo Ruby-on-Rails com um Asset Pipeline em combinação com o Nginx, o download da imagem poderá ser lento porque você estiver usando os URLs de imagem incorretos (sem impressão digital gerada pelo pipeline do ativo). Os ajudantes do Rails asset_path e image_tag geram os arquivos de formulário de URLs certos com impressão digital, que podem ser baixados rapidamente.

0x4a6f4672
fonte
1

Outra coisa muito importante a verificar é: Verifique se você tem espaço em disco restante!

Para mim foi como se segue:

[user@server]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   29G     0 100% /

Para mim, o nginx não conseguiu gravar no disco, causando o mesmo problema! Espero que ajude alguém!

Raptor
fonte
Explique por que você acha que a falta de espaço em disco pode causar o fechamento inesperado de uma conexão TCP. E como a abertura de uma nova conexão TCP resolverá temporariamente esse problema.
kasperd
1
Sim claro! Aqui está um cenário: - O Nginx está trabalhando como servidor Proxy - Ele está recebendo um arquivo do apache - O Nginx recebe o primeiro pedaço do arquivo (código de resposta 206) - Ele grava o pedaço no disco rígido e envia a solicitação para o próximo pedaço - Ele recebe o próximo pedaço e falha na gravação no disco rígido, pois não há espaço! - O Nginx fecha a conexão com o código de resposta 206. O conteúdo completo não foi veiculado no cliente! Espero que esclareça!
Raptor
1
No caso de Rush, o primeiro pedaço de imagem de tamanho 24.291 foi recebido com sucesso. O que significa que até 24.291 podem ser servidos pelo nginx diretamente da memória. É por isso que a próxima imagem com tamanho 21.404 foi veiculada com sucesso, pois não exigia gravação no HDD.
Raptor
0

Sua taxa de download é incrivelmente baixa. (2,74 KB / s!). Você obtém o mesmo resultado ao executar o wget na mesma máquina em que o Nginx está localizado? Pode ser que o Nginx esteja reagindo razoavelmente a uma solicitação por um link muito lento.

Caso contrário, recomendo explorar as várias diretrizes de tempo nos documentos do Nginx . Pesquise todas as menções a "tempo limite" na página e veja se você acha que é uma boa correspondência. Por exemplo, você pode ver que está atingindo o tempo limite em intervalos de 10 segundos, portanto, qualquer tempo limite de 10 segundos deve receber um exame adicional.

Por exemplo, a diretiva lingering_timeout é padronizada para 10 segundos, portanto você pode verificar isso.

Você também deve analisar por que a conexão com o seu cliente é aparentemente tão lenta.

Outra idéia: tente um cliente alternativo, como curl, e veja se você obtém o mesmo resultado que obtém wget. Se curlfuncionar bem, você deve suspeitar que há algo estranho em wgetfazer a solicitação.

Mark Stosberg
fonte
Isso não é problema do cliente, porque até o Firefox tem o mesmo problema. Eu tentei de uma máquina diferente em geolocalizações diferentes. O mesmo comportamento. Além disso, como você pode mencionar, a velocidade é muito boa em imagens pequenas. ps. Na máquina onde o nginx está localizado, tudo está bem. Então, tentarei cavar a diretiva de tempo limite. pps. Isso não é problema de rede, porque o link direto do apache para a mesma imagem funciona perfeitamente.
apressar
0

Verifique o valor de lingering_time no nginx.conf. Por padrão, será definido como 30seg. Portanto, o que isso fará é que o nginx esperará no máximo 30 segundos para o cliente enviar dados.

Se você estiver fazendo um upload ou POST de um arquivo que pode levar mais de 30 segundos para ser concluído, o servidor nginx redefinirá a conexão com o cliente enviando um pacote RST ao cliente se o tempo de upload exceder 30 segundos.

Para que o nginx aguarde mais tempo para ouvir os dados do cliente, defina esse valor para um valor mais alto.

Para informações detalhadas sobre lingering_time, veja aqui lingering_time

Sanath Holla
fonte