Detaillierte Erläuterung der Nginx-Prozessverwaltungs- und Neuladeprinzipien

Prozessstrukturdiagramm

Nginx ist eine Multiprozessstruktur. Die Multiprozessstruktur soll eine hohe Verfügbarkeit und Zuverlässigkeit von Nginx gewährleisten, einschließlich:

• Masterprozess: übergeordneter Prozess, der für die Verwaltung der Workerprozesse verantwortlich ist
• Worker-Prozess: ein untergeordneter Prozess. Der Worker-Prozess ist im Allgemeinen mit der gleichen Anzahl von CPU-Kernen wie der Server konfiguriert. Der Worker-Prozess wird verwendet, um bestimmte Anforderungen zu verarbeiten.
• Cache-Prozess: Dies ist ebenfalls ein Unterprozess, einschließlich der Cache-Manager- und Cache-Loader-Prozesse, die hauptsächlich als Reverse-Proxy für das Caching verwendet werden.

Hinweis: Der Grund, warum Multiprozess im Vergleich zu Multithreading eine hohe Verfügbarkeit und Zuverlässigkeit gewährleisten kann, besteht darin, dass die Adressräume zwischen den Prozessen unabhängig sind und die Aufgaben zwischen den Prozessen sich nicht gegenseitig beeinflussen. Im Vergleich zu Multithreading verbraucht es mehr CPU-Ressourcen. Da sich mehrere Threads den Adressraum eines Prozesses teilen, wirkt sich der Fehler einer Thread-Aufgabe auf die Aufgaben anderer Threads aus.

Angenommen, der Benutzer unseres Nginx-Dienstes ist nginx. Mit dem folgenden Befehl können wir den Masterprozess und den Workerprozess des aktuell ausgeführten Nginx-Dienstes anzeigen. Dabei sehen wir, dass die übergeordnete Prozess-ID der vier Workerprozesse die Prozess-ID des Masters (1325) ist.

[root@master ~]# ps -ef | grep nginx | ​​​​grep -v grep | grep -v php-fpm
root 1325 1 0 11:28 ? 00:00:00 nginx: Masterprozess /usr/local/nginx/sbin/nginx
nginx 1332 1325 0 11:28 ? 00:00:00 nginx: Arbeitsprozess
nginx 1334 1325 0 11:28 ? 00:00:00 nginx: Arbeitsprozess
nginx 1335 1325 0 11:28 ? 00:00:00 nginx: Arbeitsprozess
nginx 1336 1325 0 11:28 ? 00:00:00 nginx: Arbeitsprozess 

Wir können unsere Master- und Worker-Prozesse über lsof -i:nginx端口號anzeigen.

[root@master ~]# lsof -i:80
BEFEHL PID BENUTZER FD TYP GERÄTEGRÖSSE/AUS KNOTENNAME
nginx 1325 root 6u IPv4 22282 0t0 TCP *:http (HÖREN)
nginx 1332 nginx 6u IPv4 22282 0t0 TCP *:http (HÖREN)
nginx 1334 nginx 6u IPv4 22282 0t0 TCP *:http (HÖREN)
nginx 1335 nginx 6u IPv4 22282 0t0 TCP *:http (HÖREN)
nginx 1336 nginx 6u IPv4 22282 0t0 TCP *:http (HÖREN)

Semaphorverwaltung

Linux-Semaphor-Verwaltungsmechanismus

Signale sind eine der Kommunikationsmethoden zwischen Prozessen. Eine typische Verwendung ist: Ein Terminalbenutzer gibt einen Interrupt-Befehl ein, um die Ausführung eines Programms über den Signalmechanismus zu stoppen.

Wir können unsere Prozesse verwalten, indem wir ihnen Signale senden. Der Befehl kill -l kann die von Linux unterstützten Semaphoren anzeigen.

Insgesamt gibt es 64 Semaphoren, von denen folgende geklärt werden müssen:

kill -1 $PID: (SIGHUP) lädt den Prozess neu. Ein Daemon-Prozess, der vom Terminal getrennt ist, wird mit diesem Signal benachrichtigt, dass die Konfigurationsdatei erneut gelesen werden soll.

kill -2 $PID: (SIGINT) unterbrechen (über Strg+C);

kill -3 $PID: (SIGQUIT) Beenden der Tastatureingabe (Strg-\);

kill -9 $PID: (SIGKILL) beendet den Prozess sofort, unabhängig vom aktuellen Status des Programms;

kill -10 $PID: (SIGUSR1) $USR1 und $USR2 sind beide Semaphoren, die für benutzerdefinierte Werte reserviert sind;

töten -12 $PID:($IGUSR2)

kill -15 $PID: (SIGTERM) stoppt normalerweise einen Prozess;

kill -17 $PID: (SIGCHLD) Das Signal für die Kommunikation zwischen übergeordneten und untergeordneten Prozessen. Der übergeordnete Prozess kann viele untergeordnete Prozesse forken. Wenn ein untergeordneter Prozess auflegt, wird ein Signal an den übergeordneten Prozess gesendet.

kill kann die angegebenen Informationen an das Programm senden. Die Standardmeldung ist SIGTERM(15), die das angegebene Programm beendet. Wenn dies immer noch nicht funktioniert, können Sie mit der Meldung SIGKILL(9) versuchen, das Programm zwangsweise zu entfernen. Die Programm- oder Jobnummer kann mit dem Befehl „ps“ oder „jobs“ angezeigt werden.

kill -l # Alle unterstützten Kill-PID-Signale anzeigen
# Einen Prozess beenden kill 1024
# Beenden Sie mehrere Prozesse und trennen Sie die Prozessnummern durch Leerzeichen kill 1024 2048
# kill -9 bedeutet, den Prozess sofort zu beenden kill -9 1024

Hinweis: Strg+C: Stoppt den im Terminal laufenden Prozess. Strg+C kann das im Terminal laufende Programm (den Prozess) effektiv beenden.

Verwenden von Semaphoren zum Verwalten von Nginx-Prozessen

Nginx-Prozesse können auf folgende Arten verwaltet werden: master進程, worker進程,命令行

Verwenden Sie Semaphoren, um die Master- und Worker-Prozesse zu verwalten (es wird nicht empfohlen, Semaphoren zur Verwaltung des Worker-Prozesses zu verwenden; der Worker-Prozess sollte vom Master-Prozess verwaltet und gewartet werden).

Master-Prozess

Überwachen von Arbeitsprozessen

• KIND
  

Verwalten von Arbeitsprozessen

Empfangen von Signalen

• TERM, INT
• AUFHÖREN
• HUP
• USR1
• USR2
• WINDE

Beispiel:

Beenden Sie den Masterprozess mit dem Kill-Befehl

töten -s SIGTERM 1325

Mit dem Kill-Befehl lässt Nginx die Datei erneut einlesen. Dadurch wird der Worker-Prozess geschlossen und ein neuer Worker-Prozess generiert. Der Master-Prozess (ID) bleibt unverändert.

kill -s SIGHUP 1325

Arbeitsprozess

Empfangen von Signalen

• TERM, INT
• AUFHÖREN
• USR1
• WINDE

Obwohl es möglich ist, wird davon abgeraten, Semaphoren zur direkten Verwaltung von Arbeitsprozessen zu verwenden. Arbeitprozesse sollten vom Masterprozess verwaltet und gewartet werden.

Beispiel:

Verwenden Sie den Kill-Befehl, um einen Arbeitsprozess zu beenden. Dadurch wird ein Arbeitsprozess beendet. Linux sendet ein SIGCHLD-Signal an den übergeordneten Prozess (Masterprozess) des beendeten Arbeitsprozesses. Daher erkennt der Masterprozess, dass einer unserer untergeordneten Prozesse möglicherweise ein Problem hat, und startet einen neuen Arbeitsprozess, um die Anzahl der Arbeitprozesse beizubehalten.

töten -s SIGTERM 1332

Befehlszeile

• neu laden: HUP
• erneut öffnen: USR2
• Stopp: TERM
• quit: BEENDEN

Sie können nginx -h verwenden, um den Hilfebefehl anzuzeigen

[itbsl@master ~]$ nginx -h
Nginx-Version: nginx/1.18.0
Verwendung: nginx [-?hvVtTq] [-s Signal] [-c Dateiname] [-p Präfix] [-g Anweisungen]

Optionen:
  -?,-h: diese Hilfe
  -v: Version anzeigen und beenden
  -V: Version anzeigen und Optionen konfigurieren, dann beenden
  -t: Konfiguration testen und beenden
  -T: Konfiguration testen, sichern und beenden
  -q: Nicht-Fehlermeldungen während des Konfigurationstests unterdrücken
  -s Signal: Signal an einen Masterprozess senden: Stoppen, Beenden, Neuöffnen, Neuladen
  -p Präfix: Präfixpfad festlegen (Standard: /usr/local/nginx-1.18.0/)
  -c Dateiname: Konfigurationsdatei festlegen (Standard: conf/nginx.conf)
  -g-Direktiven: globale Direktiven aus der Konfigurationsdatei setzen

Parameterbeschreibung:

• -?,-h: Hilfe anzeigen
• -v: Nginx-Version prüfen
• -V: Nginx-Version und Kompilierungsoptionen anzeigen
• -t: Überprüfen Sie, ob die Syntax der Konfigurationsdatei korrekt ist
• -T: Überprüfen Sie, ob die Syntax der Konfigurationsdatei korrekt ist, und drucken Sie
• -q: Beim Überprüfen von Konfigurationsdateien keine Nachrichten anzeigen, die keine Fehlermeldungen enthalten
• -s: Senden Sie ein Signal an den Masterprozess. Sie können senden: Stoppen, Beenden, Erneut öffnen, Neuladen.
• -c: Konfigurationsdatei angeben
• -g: Globale Anweisungen außerhalb der Konfigurationsdatei setzen

Prinzip des Neuladens der Konfigurationsdatei

Wir wissen, dass wir nginx reibungslos aktualisieren können, indem wir ein SIGHUP-Signal an den nginx-Masterprozess senden oder den Befehl nginx -s reload verwenden, um die Konfigurationsdatei neu zu laden. Was passiert also hinter den Kulissen von nginx selbst, nachdem wir einen solchen Befehl ausgeführt haben? Wie wird ein reibungsloser Übergang zwischen neuen und alten Anfragen sichergestellt?

Laden Sie den Konfigurationsdateiprozess neu

• Senden Sie ein HUP-Signal an den Masterprozess (Neuladebefehl).
• Der Masterprozess prüft, ob die Konfigurationssyntax korrekt ist
• Der Masterprozess öffnet den Abhörport (möglich, wenn der Port in der Konfigurationsdatei geändert wird)
• Der Masterprozess startet einen neuen Worker-Subprozess unter Verwendung der neuen Konfigurationsdatei
• Der Masterprozess sendet ein QUIT-Signal an den alten Worker-Child-Prozess
• Der alte Workerprozess schließt den Abhör-Handle und beendet den Prozess nach der Verarbeitung der aktuellen Verbindung.

Wenn wir es anhand eines Diagramms beschreiben würden, sähe es folgendermaßen aus:

Grafische Analyse:

1. Der grüne Status auf der linken Seite ist der Status vor der Ausführung des Befehls nginx -s reload . Gemäß der Konfiguration meines persönlichen Hosts gibt es einen Masterprozess und vier Worker-Unterprozesse.

2. Um zu simulieren, dass der ursprüngliche Worker-Prozess nach der Verarbeitung der Anforderung nach der Ausführung des Befehls nginx -s reload beendet wird, simuliere ich eine Schnittstelle, die lange braucht, um die Aufgabe abzuschließen und zu antworten. Ja, ich schlafe im Code 15 Sekunden lang, was bedeutet, dass diese Schnittstelle 15 Sekunden braucht, um zu antworten. Die längere Zeit ist für uns praktisch, um den Zwischenzustand zu beobachten. Beachten Sie, dass die Schnittstelle angefordert wird, bevor der Befehl reload ausgeführt wird.

<?php
    Schlaf (15);
    echo json_encode(['msg' => 'hallo Welt']);die();

3. Wir wissen bereits, dass der Masterprozess die Aufgabe zur Verarbeitung an den Worker-Unterprozess übergibt. Derzeit gibt es nur eine Aufgabe, sodass nur ein Workerprozess die Aufgabe verarbeiten muss.

4. Führen Sie den Reload-Befehl aus. Der Master-Prozess erstellt 4 neue Arbeitsprozesse (die gelben Arbeitsprozesse im Bild oben) (je nach Ihrer Konfiguration) und fährt die alten, inaktiven Arbeitsprozesse (die grünen Arbeitsprozesse) herunter. Die alten Arbeitsprozesse, die Anfragen verarbeiten, werden nicht sofort heruntergefahren, sondern erst, nachdem die Anfragen verarbeitet wurden.

5. Der letzte verbleibende alte Worker-Prozess wird nach Abschluss seiner Aufgabe heruntergefahren. Die verbleibenden sind alle neue Worker-Prozesse, die durch die neue nginx.conf-Konfiguration generiert wurden. Sie können das Bild unten sehen. Der heruntergefahrene alte Worker-Prozess ist immer noch sichtbar, da er die Verarbeitung der Aufgabenschnittstelle, die oben 15 Sekunden lang schläft, noch nicht abgeschlossen hat.

Zusammenfassen

Dies ist das Ende dieses Artikels über Nginx-Prozessmanagement und Überladungsprinzipien. Weitere Informationen zu Nginx-Prozessmanagement und Überladungsprinzipien finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!