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

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

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

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.

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 

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

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ę

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

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.

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.

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

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!