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 .conf
dla 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;
}
PHP
skryptów. Nie używamphp-fpm
, po prostu biegamphp-fastcgi
, robiącphp-cgi -b 127.0.0.1:9000
. Działa bezbłędnie od 3 lat. Nie mogę zrozumieć, dlaczego rozwinęła się ta kwestia.php-cgi -b 127.0.0.1:9000
) zawiesza się sporadycznie, być może z powodu zwiększonego ruchu i braku zasobów.Odpowiedzi:
zawsze ufałbym, gdyby moje serwery internetowe mówiły mi:
502 Bad Gateway
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:
.
z mojego ograniczonego pov sugerowałbym:
źródło
Gateway
w tym przypadku jest to serwer PHP. Dziękuję Ci.restart your fastcgi_process / server
co mi pomogło, dziękiWiem, ż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:
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.źródło
Utrzymałem również to. Rozwiązano go, zwiększając
opcache
limit 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ększmemory_consumption
do poziomu wymaganego przez twoją stronę. Wyłączenieopcache
może również działać.źródło
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
źródło
W przypadku tego samego problemu po prostu ponownie uruchamiam
php-fpm
usługę, aby ją rozwiązać.Lub czasami ten problem występuje z powodu ogromnej liczby żądań. Domyślnie
pm.max_requests
php5-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ę
źródło
W moim przypadku wyłączenie rozszerzenia xdebug pomogło.
źródł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.
źródło
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.
źródło
Dla mnie było tak dlatego, że php-fpm osiągał
max_children
limit. Dziennik php-fpm dla tej puli wskazał mi właściwy kierunekźródło
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 przezmemory_limit
zmienną. Można to ustawić zaphp_admin_value[memory_limit]
pomocą pliku konfiguracyjnego PHP-FPM.Należy pamiętać, że limit pamięci dotyczy poszczególnych skryptów . W
n
procesach PHP-FPM całkowite użycie pamięci może wynosić domemory_limit * n
. Upewnij się, że Twoje urządzenie ma wystarczającą ilość miejsca w pamięci!źródło