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

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

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.

+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 


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ę


2

W moim przypadku wyłączenie rozszerzenia xdebug pomogł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.


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.


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


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!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.