Frage nginx errors "recv () ist fehlgeschlagen (104: Verbindung wurde durch Peer zurückgesetzt), während Antwortkopf von Upstream gelesen wurde"


Ich habe einen Server, der bis zum 3. Oktober 2013 um 10:50 Uhr in Ordnung war, als es anfing, zeitweise "502 Bad Gateway" -Fehler an den Client zurückzugeben.

Ungefähr 4 von 5 Browseranforderungen sind erfolgreich, aber etwa 1 von 5 schlägt mit einem 502 fehl.

Das Nginx-Fehlerprotokoll enthält viele hundert dieser Fehler.

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"

Das PHP-Fehlerprotokoll enthält jedoch keine übereinstimmenden Fehler.

Gibt es eine Möglichkeit, PHP dazu zu bringen, mir mehr Informationen darüber zu geben, warum es die Verbindung zurücksetzt?

Das ist 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;

}

Und das ist das .conf für diese Seite;

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

34
2017-10-05 11:28


Ursprung


Was hat sich an diesem Tag geändert? Ihre Anwendung oder PHP aktualisiert? Was ist deine Bewerbung? Haben Sie das Debuggen in php-fpm aktiviert? - Pothi Kalimuthu
An diesem Tag wurde nichts geändert. Die Serverkonfiguration wurde nicht geändert, auch keine PHP-Skripte. Es ist nicht genug Speicherplatz. Meine Anwendung ist nur eine Reihe von PHP Skripte. Ich benutze nicht php-fpmIch renne nur php-fastcgi indem du es tust php-cgi -b 127.0.0.1:9000. Es funktioniert seit 3 ​​Jahren ohne Fehler. Ich kann nicht herausfinden, warum es dieses Problem entwickelt hat. - Nigel Alderton
Ich hatte vor kurzem ähnliches Problem, wo Nginx über Connection Reset von Peer beim Lesen Antwort Header von Upstream beschwert wurde, in meinem Fall war es uWSGI, das war das eigentliche Problem, Neustart uWSGI behoben das Problem für mich, warum es geschah, ist ein separates Problem. - APZ
Ihr Upstream-Service ( php-cgi -b 127.0.0.1:9000 ) versagt gelegentlich, vielleicht aufgrund von erhöhtem Verkehr und Mangel an Ressourcen. - LinuxDevOps


Antworten:


Ich würde immer vertrauen, wenn meine Webserver mir sagen: 502 Bad Gateway 

  • Wie hoch ist die Verfügbarkeit Ihres fastcgi / nginx - Prozesses?
  • Überwachen Sie Netzwerkverbindungen?
  • Können Sie einen Wechsel der Besucherzahlen an diesem Tag bestätigen / ablehnen?

Was heißt das:

  • Sie FastCgi-Prozess ist nicht zugänglich von Nginx; Entweder verlangsamen oder gar nicht entsprechen. schlechtes Gateway bedeutet: nginx kann die angegebene Ressource 127.0.0.1:9000 nicht schnellcgi_passieren; in diesem ganz bestimmten Moment.

  • Ihre anfänglichen Fehlerprotokolle sagen alles:

.

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

von meinem begrenzten pov würde ich vorschlagen:

  • Starten Sie Ihren fastcgi_process / server neu
  • Überprüfen Sie Ihr Zugangsprotokoll
  • Aktivieren Sie das Debug-Protokoll

16
2017-10-06 07:26



OK. Was sagen mir meine Webserver? - Nigel Alderton
siehe meine Bearbeitung (was bedeutet das) - that guy from over there
Ich sehe, also die Gateway In diesem Fall ist der PHP-Server. Vielen Dank. - Nigel Alderton


Ich weiß, dass dieses Thema alt ist, aber es taucht immer noch gelegentlich auf. Als ich nach Antworten im Web suchte, kam ich zu den folgenden drei Möglichkeiten:

  1. Ein Programmierfehler ist manchmal segfauling php-fpm, was wiederum bedeutet, dass die Verbindung mit nginx getrennt wird. Dies wird in der Regel zumindest einige Logs und / oder Core Dumps hinterlassen, die weiter analysiert werden können.
  2. Aus irgendeinem Grund kann PHP keine Session-Datei schreiben (normalerweise: session.save_path = "/var/lib/php/sessions"). Dies können schlechte Berechtigungen, schlechte Besitzverhältnisse, schlechte Benutzer / Gruppen oder esoterischere / obskurere Probleme sein, wie das Auslaufen von Inodes in diesem Verzeichnis (oder sogar eine volle Platte!). Dies wird normalerweise nicht lassen Sie viele Core-Dumps herum und möglicherweise nicht einmal etwas in den PHP-Fehlerprotokollen.
  3. Noch schwieriger zu debuggen: eine Erweiterung ist fehlerhaft (gelegentlich trifft sie irgendeine Art von innerem Limit oder einen Fehler, der nicht immer ausgelöst wird), segfault und bringt den php-fpm-Prozess mit sich - womit die Verbindung mit nginx geschlossen wird . Die üblichen Schuldigen sind APC, Memcache / d usw. (in meinem Fall war es die New Relic-Erweiterung), also ist die Idee hier, jede Erweiterung auszuschalten, bis der Fehler verschwindet.

7
2018-06-05 23:24



+1 In meinem Fall war es # 1 - Programmierfehler. - Nimbuz
Wir sind auf diesen Fehler gestoßen und die Deaktivierung der New Relic APM PHP-Erweiterung ergab einen spezifischeren Fehler, mit dem wir das Problem aufspüren konnten: [29-Jan-2018 16:47:48 UTC] PHP Fataler Fehler: Erlaubte Speichergröße von 805306368 Bytes erschöpft (versucht, 262144 Bytes zuzuordnen) in Vendor / Magento / Modul-konfigurierbar-Produkt / Preisgestaltung / Preis / ConfigurableRegularPrice.php in Zeile 142 [29-Jan-2018 16:47:48 UTC] PHP Fataler Fehler: Erlaubte Speichergröße von 805306368 Bytes erschöpft (versucht, 323584 Bytes zuzuweisen) in Unknown in Zeile 0 Meine Vermutung ist, dass New Relic auf dem "Unbekannten" Pfad erstickt. - Erik Hansen


Habe es auch bekommen. Gelöst es durch Erhöhung der opcache Speicherlimit, wenn Sie es verwenden (Ersatz für APC). Scheint, dass PHP-FPM Verbindungen löschte, wenn der Cache zu voll wurde. Dies ist auch der Grund, warum shgnInc's Antwort es für kurze Zeit behebt.

So finden Sie die Datei /etc/php5/fpm/php.ini (oder gleichwertig in Ihrer Distribution) und erhöhen memory_consumption auf welcher Ebene auch immer Ihre Website benötigt. Deaktivierung opcache kann auch funktionieren.

[opcache]
opcache.memory_consumption = 196 

6
2018-02-02 02:34





Sie können diesen Git auf GitHub betrachten: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Ich stieß auf eine ähnliche Situation, als ich Fehlerprotokolle für meine Upstream-Server überprüfte sie einen Ulimit-Fehler gemeldet, so dass ich diese auf 1000000 erhöht (sowohl in den Upstream-und Nginx-Boxen) und alles hat gut funktioniert


2
2017-11-11 17:48





In meinem Fall des gleichen Problems starte ich einfach neu php-fpm Service so gelöst.

sudo service php5-fpm restart

Manchmal kommt dieses Problem wegen der großen Nachfrage vor. Standardmäßig ist der pm.max_requests in php5-fpm ist vielleicht 100 oder darunter.

Um es zu lösen, erhöhen Sie seinen Wert abhängig von den Anforderungen Ihrer Website, zum Beispiel 500.

Und nach dem müssen Sie den Dienst neu starten


2
2017-10-26 08:19





In meinem Fall, Deaktivieren xdebug Erweiterung hat geholfen.


1
2017-10-02 22:24





Ich hatte gerade ein ähnliches Problem:

Sie stellen eine Verbindung zu php-fpm über Port 9000 her. (Fastcgi: //127.0.0.1: 9000)

Standardkonfiguration für Ubuntu auf meinem Server ist:

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

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

Du musst das ändern zu:

listen = 0.0.0.0:9000

In meinem Fall habe ich meinen Server vor 1 1/2 Monaten aktualisiert und meine Costom-Konfiguration mit dem Standard überschrieben. Nach dem Neustart von php-fpm trat dieser Fehler mit Verzögerung auf.


0
2017-07-24 15:49