Errore Nginx + php-fpm "Timeout gateway 504" con carico quasi nullo (su un server di prova)


29

Dopo aver eseguito il debug per 6 ore - Sto rinunciando: |

Abbiamo un nginx + php-fpm + mysql in LAN con quasi 100 wordpress (creato e utilizzato da diversi designer / sviluppatori che lavorano tutti sul setup di test wordpres)

Stiamo usando nginx senza problemi da molto tempo.

Oggi, all'improvviso, nginx ha iniziato a restituire "504 Gateway Time-out" all'improvviso ...

Ho controllato il registro errori nginx per un host virtuale ...

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"

Mentre eseguo php-fpm sulla porta 9000 tramite la modalità TCP, ho eseguito "netstat | grep 9000" e ho notato qualcosa di insolito ... (Incollare l'output parziale qui per facilità di lettura)

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             

Esistono molte coppie "CLOSE_WAIT" e "FIN_WAIT2" come evidenziato di seguito (nell'output sopra):

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

Nota sopra la porta 46680.

Ho abilitato il registro errori query lente mysql, ma non ha funzionato.

A partire da ora riavviare php5-fpm ogni minuto tramite un cronjob (vedi comando sotto) mantenendo tutto in esecuzione "senza intoppi", ma odio il patchwork e voglio risolvere questo ...

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

Ho cercato ampiamente su Google - non ho avuto aiuto. Come accennato, questo è un server di prova in LAN, il carico della CPU non è mai attraversato 0.10 e anche l'utilizzo della memoria è inferiore al 25% (il sistema ha 2 GB di RAM e ubuntu-server installati) Quindi se trovi il suo tempo confuso per aiutarmi, per favore almeno lasciare un suggerimento.

Grazie in anticipo per l'aiuto.

-Rahul

(nota - questo è ripubblicare di - http://forum.nginx.org/read.php?11,127694 )

Aggiornamento: ho trovato la risposta, che è pubblicata di seguito.

Risposte:


31

Ho trovato la risposta al mio post sul forum nginx - http://forum.nginx.org/read.php?2,127854

La risposta, nel mio caso, è di impostare:

request_terminate_timeout=30s

in php-fpm config (di solito /etc/php5/fpm/php-fpm.conf)

Nota, puoi usare anche valori diversi da 30s.

L'ho usato per abbinare il mio valore nel php.inifile principale che è:

max_execution_time = 30

Ringrazia tutti. :-)


5
Questa configurazione può essere trovata anche nel file www.conf. Grazie per la risposta, però, questo sembra aver fatto il trucco.
eddiemoya,

2
Questa è una direttiva a livello di pool, riceverai un messaggio di errore quando proverai a inserirlo nella [global]sezione php-fpm.conf . Funziona lì solo se hai anche le tue configurazioni di pool. Inoltre: request_terminate_timeout docs .
tanius,

Se questa è la risposta corretta di cui HO VERAMENTE BISOGNO, questo venerdì sarà il migliore del 2015.
Filippo,

2
Ho scoperto che l'inserimento request_terminate_timeout=30snel mio php-fpm.conffile ha causato un errore (111 Connessione rifiutata). Quando l'ho spostato nel mio www.conffile ha funzionato.
AJB

Su CentOS 7.2 quando si utilizza php7, request_terminate_timeout si trova in: /etc/php-fpm.d/www.conf
nadavkav

16

Ecco come ha risolto il mio problema:

apporta le seguenti modifiche a /etc/nginx/nginx.conf nella sezione http {

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

e quindi riavviare nginx

/etc/init.d/nginx restart


2
Sì, non sembra proprio che abbia qualcosa a che fare con il problema che ha la persona che pone la domanda.
HopelessN00b

3
ma per fortuna è quello di cui avevo bisogno :)
luchaninov,

Questo non ha risolto il mio problema, ma mi ha permesso di vedere l'errore effettivo invece del messaggio di timeout, che mi ha portato al problema reale.
Michael,

4

Se stai usando php 5.3, aumenta il backlog.

Se si utilizza php 5.2, eseguire il backport della patch per aumentare la dimensione del backlog da 128.

Inoltre, utilizzare un socket unix anziché un socket TCP. unix: /tmp/php5-cgi.sock (o il percorso pertinente)


Dovrei essere d'accordo, specialmente con l'utilizzo del socket unix.
Matt

Grazie karmawhore per la risposta. Ho trovato una soluzione sulla mailing list di nginx.
rahul286,

@ rahul286 quale risposta? sono interessato!
breiti,

@breiti vedi la mia risposta qui sotto - serverfault.com/a/179136/17440
rahul286

3

Grazie mille

request_terminate_timeout = 30s

Funziona perfettamente per me

ma, ho dovuto inserire la riga in questo file: "/etc/php5/fpm/pool.d/www.conf", vale a dire nella "Sezione dei lavoratori".

PHP 5.3.21-1 - Wordpress 3.5.1

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


Ho avuto una combinazione di fattori che finiscono per causare l'errore 502 che la tua ricetta ha fatto il trucco magico! grazie mille!
Jorge Vicente Mendoza l'

2

nel mio caso (stesso messaggio di errore nginx), alcuni script php problematici non finiscono per essere eseguiti e in attesa di qualcosa, risultando senza figli php5-fpm che nginx sceglierà.

risolvere:

  1. aggiungere il limite di tempo di esecuzione altri menzionato questo post. request_terminate_timeout=30s
  2. aumentare il numero di figli. e tutto ha funzionato come un fascino. pm.max_spare_servers=16 pm.min_spare_servers=2

ora tutto ha funzionato come un fascino.


Avevo una richiesta di connessione esterna in esecuzione da tempo nel mio script php. Cerca quelle attività che durano a lungo e metti un timeout per loro.
Ali Nadalizadeh,

1

Ho avuto lo stesso problema e l'ho risolto rimuovendo completamente Apache:

yum remove httpd

Dopodiché raccomando di riavviare sia PHP che NGINX:

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart

1
Allora non avevamo apache sul nostro server. Sono contento di conoscere il tuo caso in quanto potrebbe aiutarci in futuro.
rahul286,

0

Per me lo stesso problema si è verificato dopo aver rimosso rabbitmq dal server. Nulla di quanto sopra non è stato utile, reinstallare tutti i moduli php5 ha risolto il problema. Avevo Debian 8.2 su quel server. La speranza sarà utile per qualcuno.


-1

Questo può anche aiutare la gente:

A seconda di quale sia la tua configurazione, dovresti guardare i parametri di configurazione di fastcgi e php ... nel mio caso (sto usando apache2 + php5-fpm) e il tempo di esecuzione max dipende anche da quanto tempo il modulo fastcgi attende la risposta ( -idle-timeout) ...

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


perché usare apache2 ?? Voglio dire che puoi usare nginx direttamente per interagire con php5-fpm. Non c'è bisogno di usare Apache quando hai nginx!
rahul286,

Se stai usando nginx, se gli altri NON usano nginx speriamo che questo li aiuti. :-) ... Mi sono imbattuto in questa pagina alla ricerca di Apache2 + php5-fpm domanda relativa
farinspace

ok. Ho pensato che stai usando Nginx con Apache per gli script PHP come alcuni utenti lo usavano in passato.
rahul286,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.