Parlons du redémarrage en douceur de nginx et du redémarrage en douceur de FPM

Cet article vous présentera le redémarrage en douceur et présentera en détail le redémarrage en douceur de nginx et le redémarrage en douceur de FPM. J'espère qu'il pourra vous aider !

Graceful Restart

GR est l'abréviation de Graceful Restart. Il s'agit d'un mécanisme permettant de garantir que les services de transfert ne sont pas interrompus lors du redémarrage du protocole.
Le cœur du mécanisme GR est que lorsqu'un appareil redémarre le protocole, il peut avertir les appareils environnants afin de maintenir des relations de voisinage stables et des itinéraires vers l'appareil dans un certain laps de temps. Une fois le protocole redémarré, les périphériques l'aident à synchroniser les informations (y compris diverses informations de topologie, de routage et de session maintenues par les protocoles de routage/MPLS prenant en charge GR), rétablissant ainsi l'appareil dans son état d'avant le redémarrage dans les plus brefs délais. État. Il n'y aura aucun battement de route pendant tout le processus de redémarrage du protocole, et il n'y aura aucun changement dans le chemin de transmission des paquets. L'ensemble du système peut transmettre des données sans interruption. Ce processus est appelé un redémarrage en douceur.

redémarrage en douceur de nginx

Le processus nginx est divisé en processus principal principal et processus de travail. Le redémarrage en douceur de nginx est contrôlé par le signal HUB.

Remarque : sur les plateformes compatibles POSIX, SIGUSR1 et SIGUSR2 sont des signaux envoyés à un processus qui représentent des situations définies par l'utilisateur.

Afin d'analyser en détail le processus de redémarrage en douceur de nginx, nous continuons à surveiller les modifications du processus nginx.
Envoyer le signal HUP

kill -HUP `cat /home/git/nginx/logs/nginx.pid`

Par observation, nous pouvons analyser le processus de redémarrage en douceur comme suit :
1. Le maître utilise la nouvelle configuration pour débourser n-1 travailleurs et le nouveau maître.
2. Nouveau Le travailleur gère la nouvelle demande et l'ancien travailleur quitte après l'exécution
3 Le maître recharge la configuration, pendant laquelle le nouveau maître est utilisé pour reprendre le service
4. le nouveau maître passe en mode de travail travailleur
Après le redémarrage en douceur, le numéro du processus maître n'est pas Des changements se produiront.

mise à niveau fluide de nginx

HUP n'est utilisé que pour un redémarrage en douceur, le chargement de la configuration, etc. Si vous souhaitez mettre à niveau en douceur la version de nginx et recharger le fichier binaire compilé, vous devez utiliser le signal USR2.

1. Envoyez le signal USR2

kill -USR2 `cat /home/git/nginx/logs/nginx.pid`

Observez le processus nginx, fork un nouveau maître et travailleur, à ce moment le contenu de nginx.pid a changé et nginx.pid.oldbin est généré dans le logs directory File, enregistrez l'ancien pid maître.

2. Envoyez le signal WINCH à l'ancien maître et le travailleur nginx arrêtera le service de manière gracieuse, c'est-à-dire qu'il cessera de recevoir de nouvelles requêtes, mais ne mettra pas fin aux requêtes déjà en cours. traité. Après un certain temps, tous les processus de travail de l'ancien nginx se terminent, ne laissant que le processus maître, et toutes les demandes des utilisateurs sont traitées par le nouveau processus nginx.

kill -WINCH `cat /home/git/nginx/logs/nginx.pid.oldbin`

3. Envoyez le signal QUIT à l'ancien maître, l'ancien processus nginx se termine complètement et la mise à niveau en douceur est terminée.

kill -QUIT `cat /home/git/nginx/logs/nginx.pid.oldbin`

FPM Smooth Restart

FPM (FastCGI Process Manager) est utilisé pour remplacer la plupart des fonctions supplémentaires de PHP FastCGI a été intégré après php5.3.3 Bring –enable lorsque ./configure. Le paramètre -fpm peut activer PHP-FPM.

Le redémarrage en douceur de FPM doit être contrôlé par le signal USR2, mais il est assez différent du processus de redémarrage en douceur de nginx.

kill -USR2 `cat /home/git/php/var/run/php-fpm.pid`

En continuant à observer le processus fpm, nous pouvons voir que FPM redémarre en douceur. Il doit attendre que le processus enfant se termine complètement avant de démarrer les nouveaux processus maître et enfant, puis l'ancien maître se termine.
Utilisation de strace pour une analyse plus approfondie

a révélé que le maître avait notifié à tous les processus enfants de se terminer, y compris le processus enfant qui traitait la demande.

Afin de vérifier davantage cette conclusion, écrivez un script de veille côté serveur

<?php
exec("sleep 5");
echo &#39;done&#39;;

用浏览器请求这个地址，并在此期间平滑重启fpm，请求直接502了。
nginx错误日志：

[error] 29841#0: *1646 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "localhost"

php bug#60961，也有对fpm无法优雅的实现平滑重启的说明。
难道FPM这么low？答案当时是no，实际上通过 process_control_timeout 参数可以实现我们的目标。

process_control_timeout

 设置子进程接受主进程复用信号的超时时间。可用单位：s（秒），m（分），h（小时）或者 d（天）。默认单位：s（秒）。默认值：0（关闭）。

 原则上，php-fpm会选择空闲的fastcgi进程去处理请求，在处理之前，php-fpm会给fastcgi发送信号，用来让fastcgi进程准备好接受请求处理。但是fastcgi进程并不总是能够处理请求，也就是不能总是响应该信号（比如出现假死的情况），这时候就需要设定php-fpm留给fastcgi进程响应信号的时间，如果超时了，php-fpm会想其他办法（例如选择其他fastcgi进程），这个就是process_control_timeout参数的作用。

 这个参数缺省是 0，也就是不生效，修改为10，重新验证，502已经不会再出现。

 结论：缺省情况下，PHP-FPM 无法保证平滑的执行 reload 操作，必须设置一个合理的 process_control_timeout 才行，同时需要注意的是其值不能设置的过大，否则系统可能出现严重的请求堵塞问题。

推荐学习：《PHP视频教程》

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!