Was sind Nginx Smooth Restart und FPM Smooth Restart?

Graceful Restart

GR ist die Abkürzung für Graceful Restart. Es handelt sich um einen Mechanismus, der sicherstellt, dass Weiterleitungsdienste beim Neustart des Protokolls nicht unterbrochen werden.
Der Kern des GR-Mechanismus besteht darin, dass ein Gerät, wenn es das Protokoll neu startet, seine umliegenden Geräte benachrichtigen kann, um innerhalb eines bestimmten Zeitraums stabile Nachbarschaftsbeziehungen und Routen zum Gerät aufrechtzuerhalten. Nachdem das Protokoll neu gestartet wurde, unterstützen Peripheriegeräte es bei der Synchronisierung von Informationen (einschließlich verschiedener Topologie-, Routing- und Sitzungsinformationen, die von Routing-/MPLS-bezogenen Protokollen verwaltet werden, die GR unterstützen) und stellen das Gerät in kürzester Zeit wieder in den Zustand vor dem Neustart. Zustand. Während des gesamten Protokollneustartvorgangs kommt es zu keinem Routenwechsel und es kommt zu keiner Änderung des Paketweiterleitungspfads. Das gesamte System kann Daten ohne Unterbrechung weiterleiten. Dieser Vorgang wird als reibungsloser Neustart bezeichnet.

nginx reibungsloser Neustart

Der Nginx-Prozess kann in zwei Typen unterteilt werden: Hauptprozess und Arbeitsprozess. Sein reibungsloser Neustart wird über den Signal-HUB gesteuert.

Hinweis: Auf POSIX-kompatiblen Plattformen sind SIGUSR1 und SIGUSR2 an einen Prozess gesendete Signale, die benutzerdefinierte Situationen darstellen.

Um den reibungslosen Neustartprozess von Nginx im Detail zu analysieren, überwachen wir weiterhin die Änderungen des Nginx-Prozesses.
HUP-Signal senden

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

Durch Beobachtung kann der grobe reibungslose Neustartprozess wie folgt analysiert werden:
1. Der Master verwendet die neue Konfiguration, um n-1 Worker und den neuen Master auszuteilen
2. Neu Der Worker bearbeitet die neue Anfrage und der alte Worker wird nach der Ausführung beendet.
3 Der Master lädt die Konfiguration neu, wobei der neue Master den Dienst übernimmt.
Der Master lädt die Konfiguration Neuer Master wechselt in den Worker-Arbeitsmodus
Nach dem reibungslosen Neustart wird die Master-Prozessnummer nicht geändert.

nginx reibungsloses Upgrade

HUP wird nur für einen reibungslosen Neustart, das Laden der Konfiguration usw. verwendet. Wenn Sie die Nginx-Version reibungslos aktualisieren und die kompilierte Binärdatei neu laden möchten, müssen Sie das USR2-Signal verwenden.

1. Senden Sie das USR2-Signal logs-Verzeichnisdatei, notieren Sie die alte Master-PID.

2. Senden Sie das WINCH-Signal an den alten Master, und der Nginx-Worker stoppt den Dienst ordnungsgemäß, d verarbeitet. Nach einer gewissen Zeit werden alle Worker-Prozesse des alten Nginx-Prozesses beendet, sodass nur noch der Master-Prozess übrig bleibt, und alle Benutzeranforderungen werden vom neuen Nginx-Prozess verarbeitet.

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

3. Senden Sie das QUIT-Signal an den alten Master, der alte Nginx-Prozess wird vollständig beendet und das reibungslose Upgrade ist abgeschlossen.

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

FPM Smooth Restart

FPM (FastCGI Process Manager) wird verwendet, um die meisten zusätzlichen Funktionen von PHP FastCGI zu ersetzen. FPM wurde nach php5.3.3 integriert. Bringen Sie –enable-fpm, wenn ./configure Parameter zur Aktivierung von PHP-FPM.

Der reibungslose Neustart von FPM muss durch das USR2-Signal gesteuert werden, unterscheidet sich jedoch erheblich vom reibungslosen Neustartprozess von Nginx.

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

Wenn wir den FPM-Prozess weiter beobachten, können wir sehen, dass FPM reibungslos neu startet. Es muss warten, bis der untergeordnete Prozess vollständig beendet ist, bevor der neue Master- und der untergeordnete Prozess gestartet werden, und dann wird der alte Master beendet.

Mit Strace zur weiteren Analyse

wurde festgestellt, dass der Master alle untergeordneten Prozesse zum Beenden aufgefordert hat, einschließlich des untergeordneten Prozesses, der die Anfrage verarbeitet.

Um diese Schlussfolgerung weiter zu überprüfen, schreiben Sie ein serverseitiges Schlafskript

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

Verwenden Sie den Browser, um diese Adresse anzufordern. Während dieser Zeit wird fpm reibungslos neu gestartet und die Anfrage lautet direkt 502.

nginx-Fehlerprotokoll:

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

php bug#60961, was auch erklärt, warum fpm keinen reibungslosen Neustart erreichen kann.

Ist FPM so niedrig? Die Antwort lautete damals „Nein“. Tatsächlich kann unser Ziel durch den Parameter „process_control_timeout“ erreicht werden.

Stellen Sie das Zeitlimit für den untergeordneten Prozess ein, um das Wiederverwendungssignal des Hauptprozesses zu akzeptieren. Verfügbare Einheiten: s (Sekunden), m (Minuten), h (Stunden) oder d (Tage). Standardeinheit: s (Sekunden). Standard: 0 (aus).

Grundsätzlich wählt php-fpm einen inaktiven Fastcgi-Prozess aus, um die Anfrage zu verarbeiten. Vor der Verarbeitung sendet php-fpm ein Signal an fastcgi, um den Fastcgi-Prozess auf die Annahme der Anfrage vorzubereiten. Der Fastcgi-Prozess ist jedoch nicht immer in der Lage, die Anforderung zu verarbeiten, d Wenn das Signal abläuft, überlegt sich php -fpm andere Möglichkeiten (z. B. die Auswahl anderer Fastcgi-Prozesse). Dies ist die Rolle des Parameters „process_control_timeout“.

Der Standardwert dieses Parameters ist 0, was bedeutet, dass er nicht wirksam wird. Ändern Sie ihn auf 10 und die erneute Überprüfung wird nicht mehr angezeigt.

Das obige ist der detaillierte Inhalt vonWas sind Nginx Smooth Restart und FPM Smooth Restart?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!