błędy nginx „recv () nie powiodło się (104: Resetowanie połączenia przez peer) podczas odczytu nagłówka odpowiedzi z wysyłania”

44

Mam serwer, który działał poprawnie do 3 października 2013 r. O godzinie 10:50, kiedy to zaczął sporadycznie zwracać klientowi błędy „502 Bad Gateway”.

Około 4 na 5 żądań przeglądarki kończy się powodzeniem, ale około 1 na 5 kończy się niepowodzeniem z 502.

Dziennik błędów nginx zawiera wiele setek tych błędów;

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"

Jednak dziennik błędów PHP nie zawiera żadnych pasujących błędów.

Czy istnieje sposób, aby PHP dostarczył mi więcej informacji o tym, dlaczego resetuje połączenie?

To jest 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;

}

I to jest .confdla tej strony;

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;
}
Nigel Alderton
źródło
Co zmieniło się tego dnia? Zaktualizowałeś aplikację lub PHP? Jaka jest twoja aplikacja? Czy włączyłeś debugowanie w php-fpm?
Pothi Kalimuthu
Tego dnia nic się nie zmieniło. Konfiguracja serwera nie uległa zmianie, podobnie jak skrypty PHP. Nie brakuje miejsca na dysku. Moja aplikacja to tylko zestaw PHPskryptów. Nie używam php-fpm, po prostu biegam php-fastcgi, robiąc php-cgi -b 127.0.0.1:9000. Działa bezbłędnie od 3 lat. Nie mogę zrozumieć, dlaczego rozwinęła się ta kwestia.
Nigel Alderton
Miałem ostatnio podobny problem, w którym nginx narzekał na reset połączenia przez peer podczas czytania nagłówka odpowiedzi z nadrzędnego, w moim przypadku to był uWSGI, który był prawdziwym problemem, ponowne uruchomienie uWSGI naprawiło dla mnie ten problem, ponieważ to, dlaczego tak się dzieje, jest osobnym kwestia.
APZ
Twoja usługa nadrzędna ( php-cgi -b 127.0.0.1:9000) zawiesza się sporadycznie, być może z powodu zwiększonego ruchu i braku zasobów.
LinuxDevOps

Odpowiedzi:

22

zawsze ufałbym, gdyby moje serwery internetowe mówiły mi: 502 Bad Gateway

  • jaki jest czas sprawności twojego procesu fastcgi / nginx?
  • monitorujesz połączenia sieciowe?
  • czy możesz potwierdzić / odrzucić zmianę liczby odwiedzających w ciągu tego dnia?

co to znaczy:

  • ty fastcgi-proces nie jest dostępny dla nginx; albo spowalnia, albo w ogóle nie odpowiada. zła brama oznacza: nginx nie może fastcgi_pass do zdefiniowanego zasobu 127.0.0.1:9000; w tym szczególnym momencie .

  • twoje początkowe dzienniki błędów mówią wszystko:

.

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

z mojego ograniczonego pov sugerowałbym:

  • zrestartuj proces fastcgi_process / server
  • sprawdź swój dziennik dostępu
  • włącz dziennik debugowania
ten facet stamtąd
źródło
Dobrze. Co mówią mi moje serwery sieciowe?
Nigel Alderton
zobacz moją edycję (co to znaczy)
ten facet stamtąd
2
Rozumiem, więc Gatewayw tym przypadku jest to serwer PHP. Dziękuję Ci.
Nigel Alderton
restart your fastcgi_process / serverco mi pomogło, dzięki
realtebo
11

Wiem, że ten temat jest stary, ale wciąż pojawia się od czasu do czasu, więc szukając odpowiedzi w Internecie, wpadłem na trzy następujące możliwości:

  1. Błąd programowania czasami powoduje błąd php-fpm, co z kolei oznacza, że ​​połączenie z nginx zostanie zerwane. Zwykle pozostawia to co najmniej niektóre dzienniki i / lub zrzuty pamięci, które można dalej analizować.
  2. Z jakiegoś powodu PHP nie jest w stanie napisać pliku sesji (zwykle:) session.save_path = "/var/lib/php/sessions". Mogą to być złe uprawnienia, złe własności, zły użytkownik / grupa lub bardziej ezoteryczne / niejasne problemy, takie jak brak węzłów w tym katalogu (lub nawet pełny dysk!). Zwykle nie pozostawia to wielu zrzutów rdzenia i prawdopodobnie nawet niczego w dziennikach błędów PHP.
  3. Jeszcze trudniejsze do debugowania: rozszerzenie źle funkcjonuje (czasami uderza w jakiś wewnętrzny limit lub błąd, który nie jest wywoływany przez cały czas), segfaulting i sprowadza z nim proces php-fpm - zamykając w ten sposób połączenie z nginx . Zwykłymi sprawcami są APC, memcache / d itp. (W moim przypadku było to rozszerzenie New Relic), więc tutaj chodzi o wyłączenie każdego rozszerzenia, dopóki błąd nie zniknie.
Gwyneth Llewelyn
źródło
+1 W moim przypadku było to nr 1 - błąd programowania.
Nimbuz,
Wystąpił ten błąd i wyłączenie rozszerzenia New Relic APM PHP ujawniło bardziej konkretny błąd, który pozwolił nam wyśledzić problem: [29-sty-2018 16:47:48 UTC] Błąd krytyczny PHP: Dozwolony rozmiar pamięci 805306368 bajtów wyczerpany (próbował przydzielić 262144 bajtów) w dostawcy / magento / module-configurable-product / Cennik / Cena / ConfigurableRegularPrice.php na linii 142 [29-sty-2018 16:47:48 UTC] PHP Błąd krytyczny: dozwolony rozmiar pamięci 805306368 bajtów wyczerpanych (próbowano przydzielić 323584 bajtów) w Nieznany w wierszu 0 Domyślam się, że New Relic dusił się na ścieżce „Nieznany”.
Erik Hansen
7

Utrzymałem również to. Rozwiązano go, zwiększając opcachelimit pamięci, jeśli go użyjesz (zamiennik APC). Wygląda na to, że PHP-FPM porzuciło połączenia, gdy pamięć podręczna się zapełniła. Jest to również powód, dla którego odpowiedź shgnInc naprawia ją na krótki czas.

Więc znajdź plik /etc/php5/fpm/php.ini(lub jego odpowiednik w swojej dystrybucji) i zwiększ memory_consumptiondo poziomu wymaganego przez twoją stronę. Wyłączenie opcachemoże również działać.

[opcache]
opcache.memory_consumption = 196 
Manuel Riel
źródło
2

Możesz rozważyć ten git na github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Napotkałem podobną sytuację, kiedy sprawdziłem dzienniki błędów dla moich serwerów nadrzędnych, które zgłaszały jakiś błąd ulimit, więc zwiększyłem to do 1000000 (zarówno w polu nadrzędnym, jak i nginx) i wszystko działało dobrze

Anonimowy AMG
źródło
2

W przypadku tego samego problemu po prostu ponownie uruchamiam php-fpmusługę, aby ją rozwiązać.

sudo service php5-fpm restart

Lub czasami ten problem występuje z powodu ogromnej liczby żądań. Domyślnie pm.max_requestsphp5-fpm może wynosić 100 lub mniej.

Aby go rozwiązać, jego wartość zależy od żądań witryny, na przykład 500.

A po tym musisz ponownie uruchomić usługę

shgnInc
źródło
2

W moim przypadku wyłączenie rozszerzenia xdebug pomogło.

Wasilij
źródło
to samo, w moim przypadku ustawiłem warunek dla punktu przerwania i w tym momencie wyłączyłem punkt przerwania błąd zniknął.
roman204
1

Właśnie miałem podobny problem:

Łączysz się z php-fpm na porcie 9000. (fastcgi: //127.0.0.1: 9000)

Standardowa konfiguracja Ubuntu na moim serwerze to:

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

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

musisz to zmienić na:

listen = 0.0.0.0:9000

W moim przypadku zaktualizowałem serwer 1 1/2 miesiąca temu, zastępując moją konfigurację costom ustawieniem domyślnym. Po zrestartowaniu php-fpm ten błąd zaczął działać z opóźnieniem.

Fabian Thommen
źródło
1

Dla mnie na serwerze zabrakło pamięci i php-fpm został zabity przez zabójcę OOM. Rozwiązaniem było zwiększenie ilości pamięci serwera.

Konstantin Pereiasłow
źródło
1

Dla mnie było tak dlatego, że php-fpm osiągał max_childrenlimit. Dziennik php-fpm dla tej puli wskazał mi właściwy kierunek

bruchowski
źródło
0

Ten problem może również wystąpić, jeśli proces PHP-FPM przekroczy limit przydzielonej pamięci. Kiedy tak się dzieje, połączenie między NGINX a PHP-FPM zostaje zerwane, a NGINX zwraca a 502 Bad Gateway. Limit pamięci procesu PHP-FPM jest kontrolowany przez memory_limitzmienną. Można to ustawić za php_admin_value[memory_limit]pomocą pliku konfiguracyjnego PHP-FPM.

Należy pamiętać, że limit pamięci dotyczy poszczególnych skryptów . W nprocesach PHP-FPM całkowite użycie pamięci może wynosić do memory_limit * n. Upewnij się, że Twoje urządzenie ma wystarczającą ilość miejsca w pamięci!

Francis
źródło