nginx ferme la connexion sur certaines photos

8

Il y a un problème avec nginx. Il ferme la connexion avant que le client ne termine le téléchargement. On dirait:

 $ 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]

en même temps avec des images plus petites tout va bien:

 $ 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]

C'est la raison pour laquelle cette image ne peut pas être dessinée en taille réelle dans le navigateur. Je ne peux en voir que la tête.

Nginx est configuré comme front-end et apache comme back-end. Le lien direct vers apache fonctionne bien, il y a donc un problème dans nginx. Ai-je raison?

configuration 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;
            }
    }

où dois-je creuser pour résoudre ce problème?

se ruer
la source
1
Avez-vous essayé d'éteindre sendfile?
VBart
Oui, rien n'a changé.
rush

Réponses:

9

La principale chose que j'ai oubliée est de vérifier /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"

J'ai donc corrigé les /var/lib/nginx/proxy/*permissions des répertoires ( sudo chown -R www-data:www-data /var/lib/nginx/proxy/*) et maintenant tout fonctionne très bien. Merci à tous pour votre aide.

se ruer
la source
Merci pour cela. Cela semble être un conseil évident mais je n'avais pas vérifié non plus. Dans mon cas, la cause était la suivante: [crit] 6 # 6: * 2577 mkdir () "/ var / cache / nginx / proxy_temp / 8" a échoué (28: il n'y a plus d'espace sur l'appareil) lors de la lecture en amont
Damian Moore
1

Une raison possible de la fermeture de la connexion est une connexion lente et courte keepalive_timeout. La valeur par défaut pour le keepalive_timeoutest 75s. S'il est trop court et que la connexion est lente, alors il pourrait être fermé trop tôt.

http {
    ..
    keepalive_timeout 75;
}

L'une des raisons pour lesquelles le téléchargement de votre image peut être lent est votre application. Si vous utilisez une application Ruby-on-Rails avec un pipeline d'actifs en combinaison avec Nginx, le téléchargement de l'image peut être lent car vous utilisez les mauvaises URL d'image (sans empreinte digitale générée par le pipeline d'actifs). Les aides Rails asset_path et image_tag génèrent les bons fichiers de formulaire urls avec empreinte digitale qui peuvent être téléchargés rapidement.

0x4a6f4672
la source
1

Une autre chose très importante à vérifier est la suivante: assurez-vous qu'il vous reste de l'espace disque!

Pour moi, c'était comme suit:

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

Pour moi, nginx n'a pas pu écrire sur le disque, ce qui a finalement causé le même problème! J'espère que cela aide quelqu'un!

Raptor
la source
Veuillez expliquer pourquoi vous pensez que le manque d'espace disque peut entraîner la fermeture inattendue d'une connexion TCP. Et comment l'ouverture d'une nouvelle connexion TCP résoudra temporairement ce problème.
kasperd
1
Oui bien sûr! Voici un scénario: - Nginx fonctionne comme un serveur proxy - Il reçoit un fichier d'Apache - Nginx reçoit le premier morceau du fichier (code de réponse 206) - Il écrit le morceau sur le disque dur et envoie une demande pour le prochain morceau - Il reçoit le morceau suivant et ne parvient pas à écrire sur le disque dur car il ne reste plus d'espace! - Nginx ferme la connexion avec le code de réponse 206. Le contenu complet n'a pas été servi au client! J'espère que cela clarifie!
Raptor
1
Dans le cas de Rush, le premier bloc d'image de taille 24 291 a été reçu avec succès. Ce qui signifie que ~ 24 291 peuvent être servis par nginx directement depuis la mémoire. C'est pourquoi la prochaine image de taille 21 404 a été servie avec succès car elle ne nécessitait pas d'écriture sur le disque dur.
Raptor
0

Votre taux de téléchargement est incroyablement bas. (2,74 Ko / s!). Obtenez-vous le même résultat lorsque vous exécutez wget sur la même machine où se trouve Nginx? Il se pourrait que Nginx réagisse raisonnablement à une demande sur une liaison très lente.

Sinon, je recommande d'explorer les différentes directives de temps dans les documents Nginx . Recherchez chaque mention de «timeout» sur la page et voyez si vous trouvez que c'est une bonne correspondance. Par exemple, vous pouvez voir que vous expirez dans ce qui semble être des intervalles de 10 secondes, donc tout délai d'environ 10 secondes devrait faire l'objet d'un examen supplémentaire.

Par exemple, les lingering_timeout directive est forcée à 10 secondes, de sorte que vous pouvez vérifier cela.

Vous devriez également chercher à savoir pourquoi la connexion avec votre client est apparemment si lente.

Une autre idée: essayez un autre client, comme curl, et voyez que vous obtenez le même résultat qu'avec wget. Si cela curlfonctionne bien, vous devriez soupçonner qu'il y a quelque chose d'étrange à wgetfaire la demande.

Mark Stosberg
la source
Ce n'est pas un problème client, car même Firefox a le même problème. Je l'ai essayé à partir de différentes machines dans des géolocalisations différentes. Le même comportement. De plus, comme vous pouvez le mentionner, la vitesse est plutôt bonne en petite image. ps. Sur la machine où se trouve nginx, tout est OK. Je vais donc essayer de creuser dans la directive timeout. pps. Ce n'est pas un problème de réseau, car un lien apache direct vers la même image fonctionne parfaitement.
rush
0

Vérifiez la lingering_time valeur nginx.conf. Ce sera par défaut réglé sur 30sec. Donc, ce que cela fera, c'est que nginx attendra au maximum 30 secondes pour que le client envoie des données.

Si vous effectuez un téléchargement ou un POST d'un fichier qui peut prendre plus de 30 secondes, le serveur nginx réinitialisera la connexion au client en envoyant un paquet RST au client si le temps de téléchargement dépasse 30 secondes.

Pour que le nginx attende plus de temps pour écouter les données client, définissez cette valeur sur une valeur supérieure.

Pour des informations détaillées sur lingering_time, consultez-les ici lingering_time

Sanath Holla
la source