Que sont le redémarrage en douceur nginx et le redémarrage en douceur FPM ?

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 peut être divisé en deux types : le processus principal et le processus de travail. Son redémarrage en douceur est contrôlé via le HUB de signal.

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`

Grâce à l'observation, le processus de redémarrage en douceur peut être analysé 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-fpm lorsque ./configure. paramètres pour 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;;

Utilisez le navigateur pour demander cette adresse, et pendant cette période, fpm redémarrera en douceur et la demande sera directement 502.
Journal des erreurs 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"

bug php n° 60961, qui explique également pourquoi fpm ne peut pas réaliser correctement un redémarrage en douceur.
Le FPM est-il si bas ? La réponse était non à l'époque. En fait, notre objectif peut être atteint grâce au paramètre process_control_timeout.

process_control_timeout

Définissez le délai d'attente pour que le processus enfant accepte le signal de réutilisation du processus principal. Unités disponibles : s (secondes), m (minutes), h (heures) ou d (jours). Unité par défaut : s (secondes). Par défaut : 0 (désactivé).

En principe, php-fpm sélectionnera un processus fastcgi inactif pour traiter la requête. Avant le traitement, php-fpm enverra un signal à fastcgi pour préparer le processus fastcgi à accepter le traitement de la requête. Cependant, le processus fastcgi n'est pas toujours capable de gérer la demande, c'est-à-dire qu'il ne peut pas toujours répondre au signal (comme une animation suspendue). À ce stade, vous devez définir l'heure à laquelle php-fpm part pour le processus fastcgi. répondre au signal. S'il expire, php -fpm pensera à d'autres moyens (comme sélectionner d'autres processus fastcgi), c'est le rôle du paramètre process_control_timeout.

La valeur par défaut de ce paramètre est 0, ce qui signifie qu'il ne prend pas effet. Changez-le à 10 et revérifiez que 502 n'apparaîtra plus.

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!