Detaillierte Erklärung des Nginx-Prozessplanungsproblems

Nginx verwendet eine feste Anzahl von Multiprozessmodellen, in denen ein Masterprozess (MasterProcess) und Workerprozesse mit der gleichen Anzahl von Host-CPU-Kernen zusammenarbeiten, um verschiedene Ereignisse zu verarbeiten.

Nginx verwendet eine feste Anzahl von Multiprozessmodellen, in denen ein Masterprozess (MasterProcess) und Workerprozesse mit der gleichen Anzahl von Host-CPU-Kernen zusammenarbeiten, um verschiedene Ereignisse zu verarbeiten.

Der Hauptverwaltungsprozess ist für das Laden der Konfiguration sowie das Starten und Stoppen des Arbeitsprozesses verantwortlich, und der Arbeitsprozess ist für die Verarbeitung spezifischer Anforderungen verantwortlich. Die Ressourcen zwischen den Prozessen sind unabhängig. Jeder Arbeitsprozess verarbeitet mehrere Verbindungen. Jede Verbindung wird vollständig von einem Arbeitsprozess verarbeitet. Es besteht keine Notwendigkeit, Prozesse zu wechseln, und es treten keine Probleme mit dem Ressourcenverbrauch durch den Prozesswechsel auf. In der Standardkonfiguration entspricht die Anzahl der Worker-Prozesse der Anzahl der CPU-Kerne auf dem Host. Die Affinität zwischen CPU und Prozess wird voll ausgenutzt, um den Worker-Prozess an die CPU zu binden und so die Verarbeitungsleistung der Multi-Core-CPU zu maximieren.

Der Nginx-Hauptprozess ist für die Überwachung externer Steuersignale und die Weiterleitung zugehöriger Signaloperationen an den Worker-Prozess über den Kanalmechanismus verantwortlich. Mehrere Worker-Prozesse teilen Daten und Informationen über den gemeinsamen Speicher.

Tipps: Prozessaffinität ermöglicht es, einen Prozess oder Thread auf einer bestimmten CPU (Kern) auszuführen.

Der Arbeitsprozess von Nginx verfügt über die folgenden Planungsmethoden:

• Kein Planungsmodus: Alle Arbeitsprozesse konkurrieren um die Herstellung einer Verbindung mit dem Client, wenn ein Verbindungsereignis ausgelöst wird, und beginnen mit der Verarbeitung der Clientanforderungen, wenn die Verbindung erfolgreich hergestellt wurde. Im ungeplanten Modus konkurrieren alle Prozesse um Ressourcen , aber letztendlich kann nur ein Prozess eine Verbindung mit dem Client herstellen. Dies verbraucht sofort eine große Menge an Ressourcen für das System, was als Herdenphänomen bezeichnet wird.
• Mutex-Sperrmodus: Jeder Worker-Prozess konkurriert regelmäßig um die Mutex-Sperre. Sobald ein Worker-Prozess die Mutex-Sperre erhält, bedeutet dies, dass er berechtigt ist, HTTP-Verbindungsaufbauereignisse zu empfangen, und injiziert die Socket-Überwachung des aktuellen Prozesses in die Ereignis-Engine (z. B. Epoll), um externe Verbindungsereignisse zu empfangen. Andere Arbeitsprozesse können nur die Lese- und Schreibereignisse der hergestellten Verbindung weiter verarbeiten und regelmäßig den Status des Mutex abfragen. Erst nachdem der Mutex freigegeben wurde, kann der Arbeitsprozess den Mutex ergreifen und das Recht erhalten, das HTTP-Verbindungsherstellungsereignis zu verarbeiten . Wenn die Differenz zwischen 1/8 der maximalen Anzahl von Verbindungen des Arbeitsprozesses und der verfügbaren Verbindung (free_connection) des Prozesses größer oder gleich 1 ist, wird die Möglichkeit, in dieser Runde um die Mutex-Sperre zu konkurrieren, aufgegeben und es werden keine neuen Verbindungsanforderungen akzeptiert. Es werden nur die Lese- und Schreibereignisse der hergestellten Verbindung verarbeitet. Der gegenseitige Ausschlusssperrmodus vermeidet effektiv das Herdenphänomen. Bei einer großen Anzahl kurzer HTTP-Verbindungen vermeidet dieser Mechanismus effektiv den Ressourcenverbrauch, der durch Arbeitsprozesse verursacht wird, die um Ereignisverarbeitungsrechte konkurrieren. Bei einer großen Anzahl von HTTP-Verbindungen mit aktivierten langen Verbindungen konzentriert der Mutex-Modus den Druck jedoch auf einige wenige Arbeitsprozesse, was aufgrund der ungleichmäßigen Belastung der Arbeitsprozesse zu einer Verringerung der QPS führt.
• Socket-Sharding: Socket-Sharding ist ein vom Kernel bereitgestellter Zuordnungsmechanismus, der es jedem Arbeitsprozess ermöglicht, über einen identischen Satz an Abhör-Sockets zu verfügen. Bei einer externen Verbindungsanforderung entscheidet der Kernel, welcher Socket-Listener des Arbeitsprozesses die Verbindung empfangen kann. Dadurch wird das Herd-Thundering-Phänomen wirksam vermieden und die Leistung von Multi-Core-Systemen im Vergleich zum Mutex-Lock-Mechanismus verbessert. Für diese Funktion muss beim Konfigurieren der Listen-Direktive der Parameter „reuseport“ aktiviert werden.

Tipps: In Nginx-Versionen höher als 1.11.3 ist der Mutex-Modus standardmäßig deaktiviert. Der Socket-Sharding-Modus bietet die beste Leistung, da der Linux-Kernel den Mechanismus zur Prozessplanung bereitstellt.

Dies ist das Ende dieses Artikels über die Nginx-Prozessplanung. Weitere Informationen zur Nginx-Prozessplanung 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!