Erreurs nginx «recv () a échoué (104: la connexion a été réinitialisée par un homologue) lors de la lecture de l'en-tête de la réponse à partir de l'amont»


44

J'ai un serveur qui fonctionnait correctement jusqu'au 3 octobre 2013 à 10h50, heure à laquelle il a commencé à renvoyer de manière intermittente les erreurs "502 Bad Gateway" au client.

Environ 4 demandes de navigateur sur 5 aboutissent, 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 des erreurs PHP ne contient aucune erreur correspondante.

Y at-il un moyen pour que PHP me donne plus d’informations sur les raisons pour lesquelles 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 ceci est la .confpour 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;
}

Qu'est-ce qui a changé ce jour-là? Mis à jour votre application ou PHP? Quelle est votre application? Avez-vous activé le débogage dans php-fpm?
Pothi Kalimuthu

Rien n'a été changé ce jour-là. La configuration du serveur n'a pas été modifiée, pas plus que les scripts PHP. Ce n'est pas à court d'espace disque. Mon application est juste un ensemble de PHPscripts. Je n'utilise pas php-fpm, je cours juste php-fastcgien faisant php-cgi -b 127.0.0.1:9000. Cela fonctionne sans faute depuis 3 ans. Je ne peux pas comprendre pourquoi il a développé ce problème.
Nigel Alderton

J'avais un problème similaire récemment où nginx se plaignait de la réinitialisation de la connexion par un homologue tout en lisant l'en-tête de la réponse en amont. Dans mon cas, c’était uWSGI qui était le vrai problème. Redémarrer uWSGI a corrigé le problème pour moi. problème.
APZ

Votre service en amont ( php-cgi -b 127.0.0.1:9000) échoue par intermittence, peut-être en raison d'un trafic accru et du manque de ressources.
LinuxDevOps

Réponses:


22

Je ferais toujours confiance si mes serveurs Web me disaient: 502 Bad Gateway

  • quelle est la disponibilité de votre processus fastcgi / nginx?
  • surveillez-vous les connexions réseau?
  • pouvez-vous confirmer / refuser un changement de nombre de visiteurs autour de ce jour?

Qu'est-ce que ça veut dire:

  • votre fastcgi-process n'est pas accessible par nginx; soit pour ralentir ou ne pas correspondre du tout. mauvaise passerelle signifie que nginx ne peut pas passer rapidement à la ressource définie 127.0.0.1:9000; à ce moment précis .

  • votre journal d'erreur initial dit tout:

.

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érerais:

  • redémarrez votre fastcgi_process / server
  • vérifier votre journal d'accès
  • activer le journal de débogage

D'accord. Que me disent mes serveurs web?
Nigel Alderton

voir mon montage (qu'est-ce que cela signifie)
ce gars de là-bas

2
Je vois, Gatewaydans ce cas, le serveur PHP. Merci.
Nigel Alderton

restart your fastcgi_process / serverest ce qui m'a aidé, thans
realtebo

11

Je sais que ce sujet est ancien, mais il continue à apparaître de temps en temps, alors, cherchant des réponses sur le Web, j'ai proposé les trois possibilités suivantes:

  1. Une erreur de programmation est parfois causée par la segmentation de php-fpm, ce qui signifie que la connexion avec nginx sera interrompue. Cela laissera généralement au moins quelques journaux et / ou vidages de noyau, qui peuvent être analysés plus en détail.
  2. Pour une raison quelconque, PHP n’est pas capable d’é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 tels que le manque d’inodes sur ce répertoire (ou même un disque complet!). Cela ne laissera généralement pas beaucoup de fichiers de base et peut-être même rien dans les journaux d’erreurs PHP.
  3. Encore plus délicat à déboguer: une extension se comporte mal (heurtant parfois une limite interne ou un bogue qui ne se déclenche pas tout le temps), segfaulting et amène le processus php-fpm avec elle - fermant ainsi la connexion avec nginx . Les coupables habituels sont APC, memcache / d, etc. (dans mon cas, il s’agissait de l’extension New Relic), l’idée étant ici de désactiver chaque extension jusqu’à ce que l’erreur disparaisse.

+1 Dans mon cas, il s'agissait de la première erreur - erreur de programmation.
Nimbuz

Nous avons rencontré cette erreur et la désactivation de l'extension New Relic APM PHP a révélé une erreur plus spécifique qui nous a permis de localiser le problème: [29-Jan-2018 16:47:48 UTC] Erreur irrécupérable PHP: taille de mémoire autorisée de 805306368 octets épuisé (essayé d'allouer 262144 octets) dans vendeur / magento / module-configurable-product / Prix / Prix / ConfigurableRegularPrice.php à la ligne 142 [29-Jan-2018 16:47:48 UTC] PHP Erreur fatale: taille de mémoire autorisée de 805306368 octets épuisés (tentative d'allocation de 323584 octets) dans Unknown sur la ligne 0 Mon hypothèse est que New Relic est bloquée sur le chemin "Unknown".
Erik Hansen

7

J'ai gardé ça aussi. Résolu en augmentant la opcachelimite de mémoire, si vous l'utilisez (remplacement pour APC). Il semble que PHP-FPM ait interrompu ses 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.

Recherchez donc le fichier /etc/php5/fpm/php.ini(ou l’équivalent dans votre distribution) et augmentez-le memory_consumptionau niveau requis par votre site. Désactiver opcachepeut aussi fonctionner.

[opcache]
opcache.memory_consumption = 196 

2

Vous voudrez peut-être envisager 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. J'ai donc augmenté ce nombre à 1000000 (sur les boîtes en amont et nginx) et tout s'est bien passé.


2

Dans le cas du même problème, je viens de redémarrer le php-fpmservice afin qu'il soit résolu.

sudo service php5-fpm restart

Ou parfois, ce problème se produit à cause d'une énorme demande. Par défaut, pm.max_requestsdans 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, vous devez redémarrer le service


2

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


idem, dans mon cas, j'ai posé une condition pour un point d'arrêt et à ce moment-là, j'ai désactivé le point d'arrêt, l'erreur avait disparu.
roman204

1

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 sous Ubuntu sur mon serveur est la suivante:

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

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

vous devez changer ceci en:

listen = 0.0.0.0:9000

Dans mon cas, j’ai mis à jour mon serveur il ya un an et demi, écrasant par défaut ma configuration client. Maintenant que vous avez redémarré php-fpm, cette erreur est survenue avec un retard.


1

Pour moi, c’est le serveur qui manque de mémoire et php-fpm qui est tué par le tueur OOM. La solution consistait à augmenter la quantité de mémoire du serveur.


1

Pour moi, c'était parce que php-fpm atteignait la max_childrenlimite. Le journal php-fpm de la piscine en question m'a orienté dans la bonne direction


0

Ce problème peut également survenir si un processus PHP-FPM dépasse la limite de mémoire allouée. Lorsque cela se produit, la connexion entre NGINX et PHP-FPM est interrompue et NGINX renvoie un 502 Bad Gateway. La limite de mémoire du processus PHP-FPM est contrôlée par la memory_limitvariable. Ceci peut être défini 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 à chaque script . Avec les nprocessus PHP-FPM, l'utilisation totale de la mémoire peut aller jusqu'à memory_limit * n. Assurez-vous de vérifier que votre machine dispose de suffisamment d'espace mémoire!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.