J'ai un serveur qui fonctionnait correctement jusqu'au 3 octobre 2013 à 10h50, heure à laquelle il a commencé à renvoyer par intermittence les erreurs "502 Bad Gateway" au client.
Environ 4 demandes de navigateur sur 5 aboutissent, mais environ 1 sur 5 échoue avec un 502.
Le journal des erreurs nginx contient plusieurs centaines de ces erreurs;
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"
Cependant, le journal des erreurs PHP ne contient aucune erreur correspondante.
Y at-il un moyen pour que PHP me donne plus d’informations sur les raisons pour lesquelles il réinitialise la connexion?
C'est 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;
}
Et c'est le .conf pour ce site;
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;
}
Je ferais toujours confiance si mes serveurs Web me disaient: 502 Bad Gateway
- quelle est la disponibilité de votre processus fastcgi / nginx?
- surveillez-vous les connexions réseau?
- pouvez-vous confirmer / refuser un changement de nombre de visiteurs autour de ce jour?
Qu'est-ce que ça veut dire:
votre fastcgi-process n'est pas accessible par nginx; soit pour ralentir ou ne pas correspondre du tout. mauvaise passerelle signifie que nginx ne peut pas passer rapidement à la ressource définie 127.0.0.1:9000; à ce moment précis.
votre journal d'erreur initial dit tout:
.
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???
de mon pov limité je suggérerais:
- redémarrez votre fastcgi_process / server
- vérifier votre journal d'accès
- activer le journal de débogage
Je sais que ce sujet est ancien, mais il continue à apparaître occasionnellement, alors, cherchant des réponses sur le Web, j'ai proposé les trois possibilités suivantes:
- Une erreur de programmation est parfois causée par la segmentation de php-fpm, ce qui signifie que la connexion avec nginx sera interrompue. Cela laissera généralement au moins quelques journaux et / ou vidages de noyau, qui peuvent être analysés plus en détail.
- Pour une raison quelconque, PHP n’est pas en mesure d’écrire un fichier de session (généralement:
session.save_path = "/var/lib/php/sessions"). Cela peut être de mauvaises autorisations, une mauvaise propriété, un mauvais utilisateur / groupe, ou des problèmes plus ésotériques / obscurs tels que le manque d’inodes sur ce répertoire (ou même un disque complet!). Ce sera généralement ne pas laisser beaucoup de dumps de base et peut-être même rien dans les journaux d’erreurs PHP.
- Encore plus délicat à déboguer: une extension se comporte mal (heurtant parfois une limite interne ou un bug qui ne se déclenche pas tout le temps), segfaulting et amène le processus php-fpm avec elle - fermant ainsi la connexion avec nginx . Les coupables habituels sont APC, memcache / d, etc. (dans mon cas, il s’agissait de l’extension New Relic), l’idée étant ici de désactiver chaque extension jusqu’à ce que l’erreur disparaisse.
J'ai gardé ça aussi. Résolu en augmentant le opcache limite de mémoire, si vous l'utilisez (remplacement de APC). Apparemment, PHP-FPM a interrompu ses connexions chaque fois que le cache était trop plein. C'est aussi la raison pour laquelle la réponse de shgnInc le corrige pour une courte période.
Alors trouvez le fichier /etc/php5/fpm/php.ini (ou équivalent dans votre distribution) et augmentez memory_consumption quel que soit le niveau requis par votre site. Désactiver opcache peut aussi travailler.
[opcache]
opcache.memory_consumption = 196
Vous voudrez peut-être envisager ce git sur github:
https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209
J'ai rencontré une situation similaire. Lorsque j'ai vérifié les journaux d'erreurs de mes serveurs en amont, ils signalaient une erreur ulimit. J'ai donc augmenté ce nombre à 1000000 (sur les boîtes en amont et nginx) et tout a bien fonctionné.
Dans mon cas de même problème, je viens de redémarrer le php-fpm service si résolu.
sudo service php5-fpm restart
Ou parfois, ce problème se produit à cause d'une énorme demande. Par défaut le pm.max_requests dans php5-fpm est peut-être 100 ou moins.
Pour le résoudre, augmentez sa valeur en fonction des demandes de votre site, par exemple 500.
Et après, vous devez redémarrer le service
Dans mon cas, la désactivation xdebug l'extension a aidé.
Je viens d'avoir un problème similaire:
Vous vous connectez à php-fpm sur le port 9000. (fastcgi: //127.0.0.1: 9000)
La configuration standard sur Ubuntu sur mon serveur est la suivante:
/etc/php/7.0/fpm/pool.d/www.conf:
listen = /run/php/php7.0-fpm.sock
vous devez changer ceci en:
listen = 0.0.0.0:9000
Dans mon cas, j’ai mis à jour mon serveur il ya un an et demi, écrasant par défaut ma configuration costom. Maintenant, ayant redémarré php-fpm, cette erreur est survenue avec retard.