Que dois-je faire si nginx signale l'erreur 502 ? Partage de solutions

Que dois-je faire si nginx signale l'erreur 502 ? Cet article parlera de la solution à l'erreur nginx 502. J'espère que cela sera utile à tout le monde !

Processus de requête http : dans des circonstances normales, lors de la soumission d'une requête dynamique, nginx transférera directement la requête vers php-fpm, et php-fpm allouera le processus php-cgi pour gérer les requêtes associées, puis reviendra à son tour, et enfin nginx renvoie les résultats au navigateur client.

L'erreur Nginx 502 Bad Gateway est un problème avec FastCGI

Solution

Si vous rencontrez un problème 502, vous pouvez donner la priorité à suivre les deux étapes suivantes pour le résoudre.

1. Vérifiez si le nombre actuel de processus PHP FastCGI est suffisant (valeur max_children)

netstat -anpo | grep "php-cgi"| wc -l

Si le "nombre de processus FastCGI" réel utilisé est proche du "nombre de processus FastCGI" prédéfini, indiquez le " nombre de processus FastCGI" Ce n'est pas suffisant et doit être augmenté.

2. Le temps d'exécution de certains programmes PHP dépasse le temps d'attente de Nginx (php manque de mémoire)

Augmentez le timeout FastCGI dans le fichier de configuration nginx.conf, par exemple :

    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;

en php .ini memory_limit=64M, redémarrez nginx. memory_limit=64M，重启nginx。

如果这样修改了还解决不了问题，可以参考下面这些方案：

3、max-children和max-requests

一台服务器上运行着nginx php(fpm) xcache，访问量日均 300W pv左右

最近经常会出现这样的情况： php页面打开很慢，cpu使用率突然降至很低，系统负载突然升至很高，查看网卡的流量，也会发现突然降到了很低。这种情况只持续数秒钟就恢复了

检查php-fpm的日志文件发现了一些线索：

    Sep3008:32:23.289973[NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200,cur:51200
    Sep3008:32:23.290212[NOTICE] fpm_sockets_init_main(), line 371:using inherited socket fd=10,“127.0.0.1:9000″
    Sep3008:32:23.290342[NOTICE] fpm_event_init_main(), line 109: libevent:using epoll
    Sep3008:32:23.296426[NOTICE] fpm_init(), line 47: fpm is running, pid 30587

在这几句的前面，是1000多行的关闭children和开启children的日志

原来，php-fpm有一个参数 max_requests，该参数指明了，每个children最多处理多少个请求后便会被关闭，默认的设置是500。因为php是把请求轮询给每个children，在大流量下，每个childre到达max_requests所用的时间都差不多，这样就造成所有的children基本上在同一时间被关闭。

在这期间，nginx无法将php文件转交给php-fpm处理，所以cpu会降至很低(不用处理php，更不用执行sql)，而负载会升至很高(关闭和开启children、nginx等待php-fpm)，网卡流量也降至很低(nginx无法生成数据传输给客户端)

增加children的数量，并且将 max_requests 设置未 0 或者一个比较大的值：

打开 /usr/local/php/etc/php-fpm.conf

调大以下两个参数(根据服务器实际情况，过大也不行）

    <valuename=”max_children”>5120</value>
    <valuename=”max_requests”>600</value>

然后重启php-fpm。

5、增加缓冲区容量大小

将nginx的error log打开，发现“pstream sent too big header while reading response header from upstream”这样的错误提示。查阅了一下资料，大意是nginx缓冲区有一个bug造成的,我们网站的页面消耗占用缓冲区可能过大。参考老外写的修改办法增加了缓冲区容量大小设置，502问题彻底解决。后来系统管理员又对参数做了调整只保留了2个设置参数：client head buffer，fastcgi buffer size。

6、request_terminate_timeout

如果主要是在一些post或者数据库操作的时候出现502这种情况，而不是在静态页面操作中常见，那么可以查看一下php-fpm.conf设置中的一项：request_terminate_timeout

这个值是max_execution_time

Si le problème ne peut pas être résolu après cette modification, vous pouvez vous référer aux solutions suivantes :

3, max-children et max-requests

nginx php (fpm) xcache tourne sur un serveur, avec une moyenne volume de visite quotidien de 300W pv environ

Des situations comme celle-ci se produisent souvent récemment : la page PHP s'ouvre très lentement, l'utilisation du CPU tombe soudainement à un niveau très bas, la charge du système monte soudainement à un niveau très élevé, et si vous vérifiez le trafic de la carte réseau, vous constaterez également qu'il chute soudainement à un niveau très bas. Cette situation n'a duré que quelques secondes, puis s'est rétablie

Vérifiez le fichier journal de php-fpm et trouvez quelques indices :

netstat -anpo | grep “php-cgi” | wc -l

Avant ces phrases, il y a plus de 1 000 lignes de journaux pour fermer les enfants et ouvrir les enfants

Il il s'avère que php-fpm a un paramètre max_requests, qui spécifie le nombre maximum de requêtes que chaque enfant peut gérer avant d'être arrêté. Le paramètre par défaut est 500. Étant donné que PHP interroge les requêtes de chaque enfant, en cas de trafic intense, chaque enfant met à peu près le même temps pour atteindre max_requests, ce qui entraîne la fermeture de tous les enfants pratiquement en même temps.

Pendant cette période, nginx ne peut pas transférer les fichiers php vers php-fpm pour traitement, donc le processeur tombera à un niveau très bas (pas besoin de traiter php, encore moins d'exécuter sql), et la charge augmentera à un niveau très élevé niveau (fermeture et ouverture des enfants, nginx en attente de php-fpm), le trafic de la carte réseau est également tombé à un niveau très bas (nginx ne peut pas générer de données à transmettre au client)🎜🎜Augmentez le nombre d'enfants et définissez max_requests sur inférieur à 0 ou une valeur supérieure : 🎜🎜Ouvrez /usr/local/php/etc/php-fpm.conf🎜🎜Ajoutez les deux paramètres suivants (en fonction de la situation réelle du serveur également large ne fonctionnera pas)🎜rrreee🎜Puis redémarrez php-fpm. 🎜🎜🎜5. Augmentez la capacité du tampon 🎜🎜🎜Ouvrez le journal des erreurs nginx et recherchez un message d'erreur du type "pstream a envoyé un en-tête trop gros lors de la lecture de l'en-tête de réponse depuis l'amont". Après vérification des informations, l'idée générale est qu'il y a un bug dans le tampon nginx. Le tampon occupé par la consommation des pages de notre site web est peut-être trop volumineux. En référence à la méthode de modification écrite par un étranger, le paramètre de capacité tampon est augmenté et le problème 502 est complètement résolu. Plus tard, l'administrateur système a ajusté les paramètres et n'a conservé que deux paramètres de configuration : le tampon principal du client et la taille du tampon fastcgi. 🎜🎜🎜6. request_terminate_timeout🎜🎜🎜Si 502 se produit principalement lors de certaines publications ou opérations de base de données, plutôt que commun dans les opérations de page statique, alors vous pouvez vérifier l'un des paramètres de php-fpm.conf : request_terminate_timeout 🎜🎜Cette valeur est max_execution_time, qui est le temps d'exécution du script de fast-cgi. 🎜🎜0s est fermé, ce qui signifie qu'il continuera indéfiniment. (Quand je m'habillais, j'ai changé un numéro sans bien regarder) 🎜🎜 En optimisant fastcgi, vous pouvez également modifier cette valeur pendant 5 secondes pour voir l'effet. 🎜🎜Si le nombre de processus php-cgi n'est pas suffisant, que le temps d'exécution de php est long ou que le processus php-cgi s'arrête, une erreur 502 se produira. 🎜🎜🎜Connaissances étendues : 🎜🎜🎜Nginx 502 Bad Gateway signifie que le PHP-CGI demandé a été exécuté, mais pour une raison quelconque (généralement un problème de lecture des ressources), il n'a pas été terminé et le processus PHP-CGI est terminé En général, il semble que Nginx 502 Bad Gateway soit lié aux paramètres de php-fpm.conf. 🎜🎜 php-fpm.conf a deux paramètres cruciaux, l'un est max_children et l'autre est request_terminate_timeout, mais cette valeur n'est pas universelle et doit être calculée par vous-même. Lorsqu'un problème 502 survient lors de l'installation et de l'utilisation, c'est généralement parce que le processus php-cgi par défaut est 5. Cela peut être dû à un nombre insuffisant de processus php-cgi. Vous devez modifier /usr/local/php/etc/php-. fpm.conf Augmentez la valeur max_children de manière appropriée. 🎜🎜 La méthode de calcul est la suivante : 🎜

如果你的服务器性能足够好，且宽带资源足够充足，PHP脚本没有系循环或BUG的话你可以直接将 request_terminate_timeout设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点，也就 是说你的PHP-CGI可能出现某个BUG，或者你的宽带不够充足或者其他的原因导致你的PHP-CGI假死那么就建议你给 request_terminate_timeout赋一个值，这个值可以根据服务器的性能进行设定。一般来说性能越好你可以设置越高，20分钟-30分 钟都可以。而max_children这个值又是怎么计算出来的呢？这个值原则上是越大越好，php-cgi的进程多了就会处理的很快，排队的请求就会很少。 设置max_children也需要根据服务器的性能进行设定，一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右。

按照官方的答案，排查了相关的可能，并结合了网友的答案，得出了下面的解决办法。

1、查看php fastcgi的进程数（max_children值）

netstat -anpo | grep “php-cgi” | wc -l

5（假如显示5）

2、查看当前进程

 top观察fastcgi进程数,假如使用的进程数等于或高于5个，说明需要增加（根据你机器实际状况而定）

 3、调整/usr/local/php/etc/php-fpm.conf 的相关设置

 <value name=”max_children”>10</value><value name=”request_terminate_timeout”>60s</value>max_children最多10个进程，按照每个进程20MB内存，最多200MB。request_terminate_timeout执行的时间为60秒，也就是1分钟。

推荐教程：nginx教程

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!