Erreur Nginx + php-fpm "504 Gateway Time-out" avec une charge presque nulle (sur un serveur de test)
Après avoir débogué pendant 6 heures - j'abandonne ceci: |
Nous avons un nginx + php-fpm + mysql en LAN avec près de 100 wordpress (créé et utilisé par différents designers/développeurs travaillant tous sur la configuration de wordpres de test)
Nous utilisons nginx sans problème depuis longtemps.
Aujourd'hui, tout d'un coup - nginx a commencé à renvoyer "504 Gateway Time-out" à l'improviste ...
J'ai vérifié le journal des erreurs nginx pour un hôte virtuel ...
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"
Comme je lance php-fpm sur le port 9000 via TCP, j'ai exécuté "netstat | grep 9000" et j'ai remarqué quelque chose d'inhabituel ... (Coller une sortie partielle ici pour faciliter la lecture) )
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
Il existe de nombreuses paires "CLOSE_WAIT" et "FIN_WAIT2" comme indiqué ci-dessous (dans la sortie ci-dessus):
tcp 1337 0 localhost:9000 localhost:46680 CLOSE_WAIT -
tcp 0 0 localhost:46680 localhost:9000 FIN_WAIT2 -
Veuillez noter le port 46680 ci-dessus.
J'ai activé le journal des erreurs de requêtes lentes mysql, mais cela n'a pas fonctionné.
À partir de maintenant, redémarrez php5-fpm chaque minute via un cronjob (voir la commande ci-dessous) en gardant tout fonctionnant "en douceur" mais je déteste le patchwork et je veux résoudre ce problème ...
1 * * * * service php5-fpm restart > /dev/null
J'ai effectué de nombreuses recherches sur Google - je n'ai reçu aucune aide. Comme mentionné, il s'agit d'un serveur de test en LAN, la charge du processeur n'est jamais dépassée de 0,10 et l'utilisation de la mémoire est également inférieure à 25% (le système a 2 Go RAM et ubuntu-server installé) donc si vous trouvez son prêter à confusion pour m'aider, s'il vous plaît au moins laisser un indice.
Merci d'avance pour votre aide.
-Rahul
(note - il s'agit de la rediffusion de - http://forum.nginx.org/read.php?11,127694 )
Mise à jour: j'ai trouvé la réponse, qui est publiée ci-dessous.
J'ai trouvé la réponse sur mon message sur le forum nginx - http://forum.nginx.org/read.php?2,127854
La réponse, dans mon cas, est de définir:
request_terminate_timeout=30s
dans la configuration php-fpm (généralement /etc/php5/fpm/php-fpm.conf)
Remarque, vous pouvez également utiliser des valeurs autres que 30 s.
Je l'ai utilisé pour correspondre à ma valeur dans le principal php.ini fichier qui est:
max_execution_time = 30
Merci a tous. :-)
Voici comment cela a résolu mon problème:
apporter les modifications suivantes à /etc/nginx/nginx.conf dans http {section
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
puis redémarrez nginx
/etc/init.d/nginx restart
Si vous utilisez php 5.3, augmentez l'arriéré.
Si vous utilisez php 5.2, rétroportez le patch pour augmenter la taille du backlog de 128.
Utilisez également un socket Unix plutôt qu'un connecteur TCP socket. Unix: /tmp/php5-cgi.sock (ou le chemin d'accès approprié)
Grand merci
request_terminate_timeout = 30s
Cela fonctionne parfaitement pour moi
mais, je devais insérer la ligne dans ce fichier: "/etc/php5/fpm/pool.d/www.conf" c'est-à-dire dans la "Section Travailleur".
PHP 5.3.21-1 - Wordpress 3.5.1
dans mon cas (même message d'erreur nginx), certains scripts php problématiques ne se terminent pas pour s'exécuter et attendent quelque chose, ce qui ne produit plus d'enfants php5-fpm pour nginx.
réparer:
- ajouter un délai d'exécution autre l'a mentionné ce post.
request_terminate_timeout=30s - augmenter le nombre d'enfants. et tout fonctionnait comme un charme.
pm.max_spare_servers=16pm.min_spare_servers=2
maintenant tout fonctionnait comme un charme.
Cela peut également aider les gens:
En fonction de votre configuration, vous devez regarder les paramètres de configuration de fastcgi ainsi que php ... dans mon cas (j'utilise Apache2 + php5-fpm) et le temps max_execution dépend également de la durée pendant laquelle le module fastcgi attend la réponse ( -délai d'inactivité) ...
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html#FastCgiExternalServer
Dans notre cas, le problème était que php-fpm ne pouvait pas ouvrir une session sur un partage NFS, il semble que l'un des nœuds Web ait verrouillé le répertoire, après avoir redémarré le NFS et autorisé seulement 1 nœud à y accéder, le problème a été résolu, Dieu merci
Vous devriez toujours vérifier vos journaux php-fpm, dans mon cas, l'emplacement était à / var/opt/remi/php72/log/php-fpm
vous devez également activer les journaux de scripts lents pour un meilleur débogage et vérifier le fichier www-slow.log situé dans le répertoire logs
pour vous assurer que slowlog fonctionne, assurez-vous que les paramètres suivants sont présents dans www.conf
slowlog = /var/opt/remi/php72/log/php-fpm/www-slow.log
request_slowlog_timeout = 5s
cela devrait enregistrer tout script qui dépasse 5 secondes et enregistre l'emplacement dans le code php qui rend le problème dans /var/opt/remi/php72/log/php-fpm/www-slow.log, vous pouvez changer le chemin d'accès pour répondre votre environnement
Pour moi, le même problème s'est produit après la suppression de rabbitmq du serveur. Rien de ce qui précède n'a été utile, la réinstallation de tous les modules php5 a résolu le problème. J'avais Debian 8.2 sur ce serveur. L'espoir sera utile à quelqu'un.
J'ai eu le même problème et je l'ai résolu en supprimant complètement Apache:
yum remove httpd
Après cela, je recommande de restaurer les deux PHP et NGINX:
/etc/init.d/nginx restart
/etc/init.d/php-fpm restart