Nginx + php-fpm Błąd „Limit czasu bramy 504” przy prawie zerowym obciążeniu (na serwerze testowym)

29

Po debugowaniu przez 6 godzin - rezygnuję z tego: |

Mamy nginx + php-fpm + mysql w sieci LAN z prawie 100 wordpressami (stworzonymi i używanymi przez różnych projektantów / programistów pracujących nad testową konfiguracją wordpres)

Używamy nginx bez żadnych problemów od dawna.

Dzisiaj nagle - nginx zaczął zwracać „504 Gateway Time-out” niespodziewanie ...

Sprawdziłem dziennik błędów nginx dla wirtualnego hosta ...

2010/09/06 21:24:24 [error] 12909#0: *349 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:11 [error] 12909#0: *349 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:11 [error] 12909#0: *443 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 21:25:12 [error] 12909#0: *443 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:08:32 [error] 12909#0: *1025 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:33 [error] 12909#0: *1025 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:40 [error] 12909#0: *1064 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:09:40 [error] 12909#0: *1064 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:24:44 [error] 12909#0: *1313 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"
2010/09/06 22:24:53 [error] 12909#0: *1313 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.1, server: rahul286.rtcamp.info, request: "GET /favicon.ico HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "rahul286.rtcamp.info"

Gdy uruchamiam php-fpm na porcie 9000 w trybie TCP, uruchomiłem "netstat | grep 9000" i zauważyłem coś niezwykłego ... (Wklejam tutaj częściowe wyjście dla ułatwienia odczytu)

tcp        9      0 localhost:9000          localhost:36094         CLOSE_WAIT  14269/php5-fpm  
tcp        0      0 localhost:46664         localhost:9000          FIN_WAIT2   -               
tcp     1257      0 localhost:9000          localhost:36135         CLOSE_WAIT  -               
tcp     1257      0 localhost:9000          localhost:36125         CLOSE_WAIT  -               
tcp        9      0 localhost:9000          localhost:36102         CLOSE_WAIT  14268/php5-fpm  
tcp        0      0 localhost:46662         localhost:9000          FIN_WAIT2   -               
tcp      745      0 localhost:9000          localhost:46644         CLOSE_WAIT  -               
tcp        0      0 localhost:46658         localhost:9000          FIN_WAIT2   -               
tcp     1265      0 localhost:9000          localhost:46607         CLOSE_WAIT  -               
tcp        0      0 localhost:46672         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1257      0 localhost:9000          localhost:36119         CLOSE_WAIT  -               
tcp     1265      0 localhost:9000          localhost:46613         CLOSE_WAIT  -               
tcp        0      0 localhost:46646         localhost:9000          FIN_WAIT2   -               
tcp     1257      0 localhost:9000          localhost:36137         CLOSE_WAIT  -               
tcp        0      0 localhost:46670         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1265      0 localhost:9000          localhost:46619         CLOSE_WAIT  -               
tcp     1336      0 localhost:9000          localhost:46668         ESTABLISHED -               
tcp        0      0 localhost:46648         localhost:9000          FIN_WAIT2   -               
tcp     1336      0 localhost:9000          localhost:46670         ESTABLISHED -               
tcp        9      0 localhost:9000          localhost:36108         CLOSE_WAIT  14274/php5-fpm  
tcp     1336      0 localhost:9000          localhost:46684         ESTABLISHED -               
tcp        0      0 localhost:46674         localhost:9000          ESTABLISHED 12909/nginx: worker
tcp     1336      0 localhost:9000          localhost:46666         ESTABLISHED -               
tcp     1257      0 localhost:9000          localhost:46648         CLOSE_WAIT  -               
tcp     1336      0 localhost:9000          localhost:46678         ESTABLISHED -               
tcp        0      0 localhost:46668         localhost:9000          ESTABLISHED 12909/nginx: wo

Istnieje wiele par „CLOSE_WAIT” i „FIN_WAIT2”, jak zaznaczono poniżej (w powyższej treści):

tcp     1337      0 localhost:9000          localhost:46680         CLOSE_WAIT  -               
tcp        0      0 localhost:46680         localhost:9000          FIN_WAIT2   -

Uwaga: port 46680 powyżej.

Włączyłem dziennik błędów powolnych zapytań mysql, ale to nie działało.

Odtąd restartuję php5-fpm co minutę przez cronjob (patrz polecenie poniżej), utrzymując wszystko "płynnie", ale nienawidzę patchworku i chcę rozwiązać ten ...

1 * * * * service php5-fpm restart > /dev/null

Szukałem intensywnie w Google - nie otrzymałem pomocy. Jak wspomniano, jest to serwer testowy w sieci LAN, obciążenie procesora nigdy nie jest przekraczane 0,10, a użycie pamięci jest również niższe niż 25% (System ma zainstalowaną 2 GB pamięci RAM i zainstalowany serwer Ubuntu). Więc jeśli uważasz, że jego pomieszanie czasu jest dla mnie pomocne, proszę przynajmniej upuść podpowiedź.

Z góry dziękuję za pomoc.

-Rahul

(uwaga - to jest ponowne publikowanie - http://forum.nginx.org/read.php?11,127694 )

Aktualizacja: Znalazłem odpowiedź, która jest opublikowana poniżej.

nginx fastcgi timeout gateway php-fpm rahul286
źródło

Odpowiedzi:

31

Znalazłem odpowiedź na mój post na forum nginx - http://forum.nginx.org/read.php?2,127854

W moim przypadku odpowiedź brzmi:

request_terminate_timeout=30s

w konfiguracji php-fpm (zwykle /etc/php5/fpm/php-fpm.conf)

Uwaga: możesz także użyć wartości innych niż 30s.

Użyłem go, aby dopasować moją wartość w głównym php.inipliku, który jest:

max_execution_time = 30

Dziękuje wszystkim. :-)

rahul286
źródło
5
Tę konfigurację można również znaleźć w pliku www.conf. Dzięki za odpowiedź, wydaje się, że to załatwiło sprawę.
eddiemoya,
2
Jest to dyrektywa na poziomie puli, podczas próby umieszczenia jej w sekcji php-fpm.conf pojawi się komunikat o błędzie [global]. Działa tam tylko wtedy, gdy masz tam również konfiguracje puli. Ponadto: request_terminate_timeout docs .
tanius
Jeśli to jest poprawna odpowiedź, której NAPRAWDĘ POTRZEBUJĘ, to ten piątek będzie najlepszym z 2015 roku.
Philip
2
Odkryłem, że wstawienie request_terminate_timeout=30sdo mojego php-fpm.confpliku spowodowało błąd (111 odmowy połączenia). Kiedy przeniosłem go do mojego www.confpliku, zadziałało.
AJB
W CentOS 7.2, gdy używasz php7, request_terminate_timeout znajduje się w: /etc/php-fpm.d/www.conf
nadavkav
16

Oto jak rozwiązał mój problem:

wprowadź następujące zmiany w /etc/nginx/nginx.conf w http {sekcja

proxy_connect_timeout  600s;
proxy_send_timeout  600s;
proxy_read_timeout  600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;

a następnie uruchom ponownie nginx

/etc/init.d/nginx restart

Vijay Kumar
źródło
2
Tak, to naprawdę nie wygląda na to, że ma to coś wspólnego z problemem osoby zadającej pytanie.
HopelessN00b,
3
ale na szczęście tego właśnie potrzebowałem :)
luchaninov
To nie rozwiązało mojego problemu, ale pozwoliło mi zobaczyć rzeczywisty błąd zamiast komunikatu o przekroczeniu limitu czasu, co doprowadziło mnie do faktycznego problemu.
Michael
4

Jeśli używasz php 5.3, zwiększ zaległości.

Jeśli używasz php 5.2, cofnij łatkę, aby zwiększyć rozmiar zaległości ze 128.

Ponadto używaj gniazda unix zamiast gniazda TCP. unix: /tmp/php5-cgi.sock (lub odpowiednia ścieżka)

karmawhore
źródło
Muszę się zgodzić, zwłaszcza jeśli chodzi o użycie gniazda unix.
Matt
Dzięki karmawhore za odpowiedź. Znalazłem rozwiązanie na liście mailingowej nginx.
rahul286
@ rahul286 które odpowiedzi? jestem zainteresowany!
breiti
@breiti zobacz mój anser poniżej - serverfault.com/a/179136/17440
rahul286
3

Wielkie dzięki

request_terminate_timeout = 30s

Działa dla mnie idealnie

ale musiałem wstawić wiersz w tym pliku: „/etc/php5/fpm/pool.d/www.conf”, to znaczy w „części roboczej”.

PHP 5.3.21-1 - Wordpress 3.5.1

http://php-fpm.org/wiki/Configuration_File

Franck
źródło
Miałem kombinację czynników, które ostatecznie spowodowały błąd 502, którego przepis zrobił magiczną sztuczkę! bardzo Ci dziękuję!
Jorge Vicente Mendoza
2

w moim przypadku (ten sam komunikat o błędzie nginx), niektóre problematyczne skrypty php nie kończą się na wykonywaniu i nie czekają na coś, co skutkuje brakiem dzieci php5-fpm dla nginx do wybrania.

naprawić:

  1. dodaj limit czasu realizacji inne wspomniano w tym poście. request_terminate_timeout=30s
  2. podnieść liczbę dzieci. i wszystko działało jak urok. pm.max_spare_servers=16 pm.min_spare_servers=2

teraz wszystko działało jak urok.

c2h2
źródło
Miałem długo działające żądanie zewnętrznego połączenia w moim skrypcie php. Poszukaj tych długotrwałych zadań i ustal dla nich limit czasu.
Ali Nadalizadeh,
1

Miałem ten sam problem i rozwiązałem go całkowicie usuwając Apache:

yum remove httpd

Następnie polecam przywrócenie zarówno PHP, jak i NGINX:

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart
Nikolay
źródło
1
Wtedy nie mieliśmy apache na naszym serwerze. Cieszę się, że znasz swoją sprawę, ponieważ może nam to pomóc w przyszłości.
rahul286
0

Dla mnie ten sam problem wystąpił po usunięciu rabbitmq z serwera. Nic z powyższego nie było przydatne, ponowna instalacja wszystkich modułów php5 rozwiązała problem. Miałem Debiana 8.2 na tym serwerze. Nadzieja będzie dla kogoś pomocna.

Taggart Comet
źródło
-1

Może to również pomóc ludziom:

W zależności od konfiguracji powinieneś przyjrzeć się parametrom konfiguracyjnym fastcgi, a także php ... w moim przypadku (używam apache2 + php5-fpm), a maksymalny czas wykonania zależy również od tego, jak długo moduł fastcgi czeka na odpowiedź ( -idle-timeout) ...

http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer

farinspace
źródło
dlaczego warto korzystać z Apache2? Mam na myśli, że możesz używać nginx bezpośrednio do interakcji z php5-fpm. Nie musisz używać Apache, jeśli masz nginx!
rahul286
Jeśli używasz nginx, jeśli inni NIE używają nginx, mam nadzieję, że to im pomoże. :-) ... Natknąłem się na tę stronę, szukając pytania związanego z Apache2 + php5-fpm
farinspace
dobrze. Myślałem, że używasz Nginx z skryptami Apache do skryptów PHP, tak jak niektórzy ludzie używali go w przeszłości.
rahul286