Lassen Sie uns über den reibungslosen Neustart von Nginx und den reibungslosen Neustart von FPM sprechen

Dieser Artikel führt Sie in den reibungslosen Neustart ein und stellt den reibungslosen Neustart von Nginx und den reibungslosen FPM-Neustart im Detail vor. Ich hoffe, er kann Ihnen helfen!

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 beim Neustart des Protokolls seine umliegenden Geräte benachrichtigen kann, um innerhalb eines bestimmten Zeitraums stabile Nachbarschaftsbeziehungen und Routen zum Gerät aufrechtzuerhalten. Nach dem Neustart des Protokolls 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), sodass das Gerät in den Zustand vor dem Neustart wiederhergestellt werden kann kürzestmöglicher 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 ist in einen Master-Hauptprozess und einen Arbeitsprozess unterteilt. Der reibungslose Neustart von Nginx wird durch 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 können wir den groben reibungslosen Neustartprozess wie folgt analysieren:
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. Dabei übernimmt der neue Master den Dienst. 4. Der Master lädt die Konfiguration und den neuen Der Master wechselt in den Worker-Arbeitsmodus. Nach dem reibungslosen Neustart ändert sich die Master-Prozessnummer nicht. Es werden Änderungen vorgenommen.



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, wenn ./configure Der Parameter -fpm kann PHP-FPM aktivieren.

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

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

Wenn wir den FPM-Prozess weiterhin 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

<?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视频教程》

Das obige ist der detaillierte Inhalt vonLassen Sie uns über den reibungslosen Neustart von Nginx und den reibungslosen Neustart von FPM sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!