web-dev-qa-db-fra.com

erreur nginx "échec de recv () (104: réinitialisation de la connexion par l'homologue) lors de la lecture de l'en-tête de réponse en amont"

J'ai un serveur qui fonctionnait bien jusqu'au 3 octobre 2013 à 10 h 50, date à laquelle il a commencé à renvoyer par intermittence des erreurs "502 Bad Gateway" au client.

Environ 4 demandes de navigateur sur 5 réussissent, mais environ 1 sur 5 échoue avec un 502.

Le journal des erreurs nginx contient plusieurs centaines de ces erreurs;

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"

Cependant, le journal d'erreurs PHP ne contient aucune erreur correspondante.

Existe-t-il un moyen d'obtenir PHP pour me donner plus d'informations sur la raison pour laquelle il réinitialise la connexion?

C'est 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;

}

Et c'est le .conf pour ce site;

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;
}
phpnginx
47
Nigel Alderton

je ferais toujours confiance si mes serveurs Web me disent: 502 Bad Gateway

  • quel est le temps de disponibilité de votre processus fastcgi/nginx?
  • surveillez-vous les connexions réseau?
  • pouvez-vous confirmer/refuser un changement de nombre de visiteurs autour de cette journée?

qu'est-ce que ça veut dire:

  • votre processus fastcgi n'est pas accessible par nginx; soit à ralentir soit à ne pas correspondre du tout. une mauvaise passerelle signifie: nginx ne peut pas accélérer le passage à cette ressource définie 127.0.0.1:9000; à ce moment très précis.

  • vos journaux d'erreurs initiaux en disent long:

.

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???

de mon pov limité, je suggère:

  • redémarrez votre fastcgi_process/server
  • vérifiez votre journal d'accès
  • activer le journal de débogage
22
that guy from over there

Je sais que ce sujet est ancien, mais il continue d'apparaître de temps en temps, donc, à la recherche de réponses sur le Web, j'ai trouvé les trois possibilités suivantes:

  1. Une erreur de programmation est parfois un défaut de php-fpm, ce qui signifie que la connexion avec nginx sera rompue. Cela laissera généralement au moins quelques journaux et/ou vidages de mémoire, qui peuvent être analysés plus en détail.
  2. Pour une raison quelconque, PHP ne peut pas écrire un fichier de session (généralement: session.save_path = "/var/lib/php/sessions"). Cela peut être de mauvaises autorisations, une mauvaise propriété, un mauvais utilisateur/groupe ou des problèmes plus ésotériques/obscurs comme le manque d'inodes sur ce répertoire (ou même un disque plein!). En général, cela pas laissera de nombreux vidages de mémoire autour et peut-être même rien sur les journaux d'erreurs PHP.
  3. Encore plus délicat à déboguer: une extension se comporte mal (atteignant parfois une sorte de limite interne, ou un bogue qui n'est pas déclenché tout le temps), segfaulting, et arrêter le processus php-fpm avec elle - fermant ainsi la connexion avec nginx . Les coupables habituels sont APC, memcache/d, etc. (dans mon cas, c'était l'extension New Relic), donc l'idée ici est de désactiver chaque extension jusqu'à ce que l'erreur disparaisse.
13
Gwyneth Llewelyn

J'ai continué à recevoir ça aussi. Résolu en augmentant la limite de mémoire opcache, si vous l'utilisez (remplacement d'APC). Il semble que PHP-FPM ait interrompu les connexions chaque fois que le cache était trop plein. C'est aussi la raison pour laquelle la réponse de shgnInc le corrige pour une courte période.

Alors trouvez le fichier /etc/php5/fpm/php.ini (ou équivalent dans votre distribution) et augmentez memory_consumption au niveau requis par votre site. La désactivation de opcache peut également fonctionner.

[opcache]
opcache.memory_consumption = 196
8
Manuel Riel

Vous voudrez peut-être considérer ce git sur github: https://Gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

J'ai rencontré une situation similaire, lorsque j'ai vérifié les journaux d'erreurs de mes serveurs en amont, ils signalaient une erreur ulimit, alors j'ai augmenté cela à 1000000 (sur les boîtes en amont et nginx) et tout a bien fonctionné

2
AMG Anonymous

Dans mon cas de même problème, je redémarre simplement le php-fpm service donc il a résolu.

Sudo service php5-fpm restart

Ou parfois, ce problème se produit en raison de nombreuses demandes. Par défaut, le pm.max_requests en php5-fpm est peut-être 100 ou moins.

Pour le résoudre, augmentez sa valeur en fonction des demandes de votre site, par exemple 500.

Et après le, vous devez redémarrer le service

2
shgnInc

Dans mon cas, la désactivation de l'extension xdebug a aidé.

2
Vasiliy

Pour moi, c'était le serveur qui manquait de mémoire et php-fpm se faisait tuer par le tueur OOM. La solution consistait à augmenter la quantité de mémoire du serveur.

1
Konstantin Pereiaslov

Pour moi, c'était parce que php-fpm frappait le max_children limite. Le journal php-fpm de la piscine en question m'a indiqué la bonne direction

1
bruchowski

Je viens d'avoir un problème similaire:

Vous vous connectez à php-fpm sur le port 9000. (fastcgi: //127.0.0.1: 9000)

La configuration standard sur Ubuntu sur mon serveur est:

/etc/php/7.0/fpm/pool.d/www.conf:

listen = /run/php/php7.0-fpm.sock

vous devez changer cela en:

listen = 0.0.0.0:9000

Dans mon cas, j'ai mis à jour mon serveur il y a 1 1/2 mois, en remplaçant ma configuration costom par défaut. Maintenant que vous avez redémarré php-fpm, cette erreur s'est produite avec retard.

1
Fabian Thommen

Ce problème peut également survenir si un processus PHP-FPM dépasse sa limite de mémoire allouée. Dans ce cas, la connexion entre NGINX et PHP-FPM est rompue et NGINX renvoie un 502 Bad Gateway. La limite de mémoire du processus PHP-FPM est contrôlée par le memory_limit variable. Cela peut être défini avec php_admin_value[memory_limit] dans le fichier de configuration PHP-FPM.

Il est important de noter que la limite de mémoire s'applique sur une base par script. Avec les processus n PHP-FPM, l'utilisation totale de la mémoire peut aller jusqu'à memory_limit * n. Assurez-vous de vérifier que votre machine a suffisamment de marge de mémoire!

0
Francis