it-swarm.com.de

Optimaler Wert für Nginx worker_connections

Nginx worker_connections "legt die maximale Anzahl gleichzeitiger Verbindungen fest, die von einem Arbeitsprozess geöffnet werden können. Diese Anzahl umfasst alle Verbindungen (z. B. Verbindungen mit Proxyservern usw.), nicht nur Verbindungen mit Clients. Eine weitere Überlegung ist, dass die tatsächliche Die Anzahl der gleichzeitigen Verbindungen darf die aktuelle Grenze für die maximale Anzahl geöffneter Dateien nicht überschreiten. " Ich habe einige Fragen dazu:

  1. Was sollte der optimale oder empfohlene Wert dafür sein?
  2. Was sind die Nachteile einer hohen Anzahl von Worker-Verbindungen?
30
Aarti

Nehmen wir den pragmatischen Ansatz.

All diese Grenzwerte wurden im letzten Jahrhundert fest codiert und entwickelt, als die Hardware langsam und teuer war. Wir sind jetzt im Jahr 2016. Ein durchschnittlicher Wall-Mart-Toaster kann mehr Anforderungen als die Standardwerte verarbeiten.

Die Standardeinstellungen sind tatsächlich gefährlich. Hunderte von Benutzern auf einer Website zu haben, ist nichts Beeindruckendes.

arbeiterprozess

Lassen Sie uns eine verwandte Einstellung erklären, während wir uns mit dem Thema befassen.

nginx als Load Balancer :

  • 1 Worker für den HTTP-Lastausgleich.
  • 1 Worker pro Kern für den HTTPS-Lastausgleich.

Nginx als Webserver :

Dieser ist schwierig.

Einige Anwendungen/Frameworks/Middleware (z. B. php-fpm) werden außerhalb von nginx ausgeführt. In diesem Fall reicht 1 Nginx-Worker aus, da normalerweise die externe Anwendung die umfangreiche Verarbeitung und den Verzehr der Ressourcen übernimmt.

Außerdem können einige Anwendungen/Frameworks/Middleware jeweils nur eine Anforderung verarbeiten, und es schlägt fehl, sie zu überlasten.

Im Allgemeinen ist 1 Arbeiter immer eine sichere Wette.

Andernfalls können Sie einen Mitarbeiter pro Kern einsetzen, wenn Sie wissen, was Sie tun. Ich würde diesen Weg als Optimierung betrachten und ein angemessenes Benchmarking und Testen empfehlen.

worker_connections

Die Gesamtzahl der Verbindungen beträgt worker_process * worker_connections. Die Hälfte im Load Balancer-Modus.

Jetzt erreichen wir den Toasterteil. Es gibt viele stark unterschätzte Systemgrenzen :

  • ulimits ist maximal 1k offene Dateien pro Prozess unter Linux (1k soft, 4k hard in einer Distribution)
  • die systemd-Grenzwerte entsprechen in etwa den ulimits.
  • der Nginx-Standardwert beträgt 512 Verbindungen pro Worker.
  • Es könnte mehr geben: SELinux, sysctl, Supervisord (jede Distribution + Version ist etwas anders)

1k worker_connections

Die sichere Standardeinstellung ist, überall 1k zu setzen.

Es ist hoch genug, um mehr zu sein, als die meisten internen und unbekannten Websites jemals antreffen werden. Es ist niedrig genug, um keine anderen Systemgrenzen zu erreichen.

10k worker_connections

Es ist sehr üblich, Tausende von Kunden zu haben, insbesondere für eine öffentliche Website. Ich habe aufgehört zu zählen, wie viele Websites ich gesehen habe, weil die Standardeinstellungen niedrig waren.

Das für die Produktion akzeptable Minimum beträgt 10.000. Die zugehörigen Systemgrenzen müssen erhöht werden, um dies zu ermöglichen.

Es gibt kein zu hohes Limit (ein Limit hat einfach keine Auswirkung, wenn keine Benutzer vorhanden sind). Ein zu niedriges Limit ist jedoch eine sehr reale Sache, die zu abgelehnten Benutzern und einer toten Site führt.

Mehr als 10k

10k ist schön und einfach.

Wir könnten willkürliche 1000kk-Limits festlegen (es ist immerhin nur ein Limit), aber das macht praktisch nicht viel Sinn, wir bekommen diesen Verkehr nie und können ihn sowieso nicht nehmen.

Bleiben wir bei 10k als vernünftige Einstellung. Die Dienste, die mehr wollen (und wirklich können), erfordern spezielles Tuning und Benchmarking.

Spezielles Szenario: Erweiterte Verwendung

Manchmal wissen wir, dass der Server nicht über viele Ressourcen verfügt, und wir erwarten Spitzen, gegen die wir nicht viel tun können. Wir lehnen Benutzer lieber ab als es zu versuchen. Legen Sie in diesem Fall ein angemessenes Verbindungslimit fest und konfigurieren Sie nette Fehlermeldungen und -behandlungen.

Manchmal funktionieren die Backend-Server gut und gut, aber nur bis zu einer Last , mehr und alles geht schnell nach Süden. Wir möchten lieber langsamer fahren, als dass die Server abstürzen. Konfigurieren Sie in diesem Fall die Warteschlange mit strengen Grenzwerten, und lassen Sie nginx die gesamte Wärme puffern, während die Anforderungen mit einer begrenzten Geschwindigkeit abgelassen werden.

37
user5994461

ulimit -a Gibt an, wie viele geöffnete Dateien Ihr System für einen Prozess verwenden kann.

Außerdem legt net.ipv4.ip_local_port_range Den Gesamtbereich der Sockets fest, die pro IP aktiviert werden sollen.

Ihr worker_connections Kann also nicht mehr als einer von diesen sein, oder Ihre Client-Verbindungen werden bis net.core.netdev_max_backlog In die Warteschlange gestellt - die Gesamtgröße der TCP-Warteschlange).

Beachten Sie, dass bei Verwendung von Nginx als Reverse-Proxy zwei Sockets pro Verbindung verwendet werden. Vielleicht möchten Sie ein wenig mit net.ipv4.tcp_fin_timeout Und anderen Kernel-TCP-bezogenen Timeouts spielen, um zu versuchen, den Status von Sockets schnell zu ändern. Beachten Sie außerdem, dass jeder Socket Speicher des Speicherstapels TCP) zuweist. Sie können auch einige Grenzen des Speicherstapels TCP mit sysctl können Sie mehr Druck auf das RAM ausüben, solange Sie über CPU und genügend Dateihandler verfügen).

Zu Ihrer Information, es ist möglich, bei genügend Rechenressourcen einen Server mit etwa 32 GB RAM und einige virtuelle Netzwerkschnittstellen zu haben, um 1 MM gleichzeitige Verbindungen mit einigen Kernel-Optimierungen mit sysctl zu verarbeiten. Während meiner Tests, bei denen mehr als 1 MM verarbeitet wurden und eine Nutzlast von ca. 700 Byte gesendet wurde, benötigte der Server ca. 10 Sekunden, um ca. 1,2 MM gleichzeitige Clients zu aktualisieren. Als nächstes sollte die Netzwerkbandbreite erhöht werden, indem einige zusätzliche Netzwerkkarten verbunden und virtuelle Netzwerkkarten entfernt wurden. Angesichts der Nutzlast, der Bandbreite und der angemessenen Zeit für die Aktualisierung aller Clients ist es möglich, eine Pseudo-Echtzeitkommunikation mit mehr als 1,2 MM Clients zu erreichen.

Viel Spaß beim Stimmen!

13
Marcel

Die Antwort von Marcel muss wirklich positiv bewertet werden! Wenn ulimits auf einen Standardwert von ca. 1k festgelegt sind, sollte max_connections auf denselben Wert festgelegt werden, da die Einstellung von max_connections auf 10k keinen Vorteil hat.

Sie erhalten eine Warteschlangenanforderung und Sockets, die auf nginx geschlossen werden, wenn "Ihre worker_connections nicht mehr als eine dieser Verbindungen sein können oder Ihre Clientverbindungen bis net.core.netdev_max_backlog anstehen - die Gesamtgröße von TCP Warteschlange."

Ein einzelner Prozess kann geöffnet werden, ebenso wie die Verbindung dies zulässt. num_workers * max_connections ist die Formel, aber außerhalb von Loadbalancer/Proxy müssen max-Verbindungen und ulimits für angemessene Werte berücksichtigt werden. Das Setzen von max_connection auf einen wirklich hohen Wert kann nach hinten losgehen, da ulimits ein begrenzender Faktor sind.

1
Cryptophobia

Die geeignete Größe kann durch Testen ermittelt werden, da sie je nach Art des von Nginx verarbeiteten Datenverkehrs variabel ist.

Theoretisch kann nginx Folgendes verarbeiten: max clients = worker_processes * worker_connections (* = multiplizieren) und worker_processes = Anzahl der Prozessoren

Um Prozessoren herauszufinden, verwenden Sie: grep processor/proc/cpuinfo | wc -l

1
Sachin Gargya

Das Festlegen von Untergrenzen kann hilfreich sein, wenn Sie möglicherweise über Ressourcenbeschränkungen verfügen. Einige Verbindungen, z. B. Keep-Alive-Verbindungen (nicht nur mit den Clients, sondern auch mit den Upstream-Servern ), verschwenden effektiv Ihre Ressourcen ( selbst wenn nginx sehr effizient ist (was es ist) und nicht für den korrekten Betrieb eines Allzweckservers erforderlich ist, was bedeutet, dass sie sicher gelöscht werden können, um mehr Ressourcen für den Rest des Vorgangs verfügbar zu machen.

Ein niedrigeres Ressourcenlimit würde nginx daher anzeigen, dass Sie möglicherweise nur noch wenige physische Ressourcen haben. Die verfügbaren Ressourcen sollten neuen Verbindungen zugewiesen werden, anstatt die im Leerlauf befindlichen Keep-Alive-Verbindungen auf Kosten neuerer Verbindungen zu bedienen, für die Probleme beim Aufbau bestehen dienen den dringlicheren Bedürfnissen.

Was ist der empfohlene Wert? Es ist die Standardeinstellung.

Die Standardeinstellungen sind alle in der Dokumentation dokumentiert:

Standard: worker_connections 512;

Und kann auch auf Quellcode-Ebene unter event/ngx_event.c bestätigt werden

13 # DEFAULT_CONNECTIONS definieren 512

0
cnst