Wir haben ein NGINX mit vielen virtuellen Hosts (~600) am Laufen. Leider verwenden die NGINX-Worker jeweils einen großen Teil des Residential Memory (~6 GB).
Bei der Überprüfung des Speichers (Zeichenfolgen) werden die doppelten Metadaten angezeigt, die Sie normalerweise in SSL-Zertifikaten finden (bis zu über 100.000 Mal dupliziert). Wir verwenden nur eine Handvoll verschiedener Zertifikate.
Ich vermutete, dass ssl_session_cache der Übeltäter sein könnte. Es ist eingestellt auf
ssl_session_cache gemeinsam genutzt: SSL: 10 m;
was sich gut zu unserem Speicherverbrauch addieren würde (10MB*600=6GB) Aber laut den Dokumentenhttp://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache
Ein Cache mit gleichem Namen kann in mehreren virtuellen Servern verwendet werden.
Und eine Erhöhung dieses Wertes hat offenbar keine Auswirkungen auf die Speichernutzung.
Wir verlassen uns auch stark auf Lua-Resty, aber das sollte keinen Einfluss darauf haben, wie SSL gehandhabt wird?
Wissen Sie, was die Ursache für diesen hohen Speicherverbrauch sein könnte?
Nginx-Version: openresty/1.13.6.1
Antwort1
Ich gehe davon aus, dass dies daran liegt, dass nginx für die Einstellungen jedes virtuellen Servers einen separaten Speicher reserviert hat und dieser Speicherbereich eine Kopie des verwendeten Zertifikats enthält. Dies bedeutet, dass selbst wenn Sie nur wenige separate Zertifikate haben, diese im Speicher dupliziert werden, wenn sie in separaten virtuellen Servern verwendet werden.
Der SSL-Sitzungscache enthält keine Zertifikatsdaten, sondern nur Sitzungsdaten für aktive SSL-Sitzungen zwischen Clients und Server.
Antwort2
Wir haben Openresty hauptsächlich zur Authentifizierung verwendet. Da wir vermuteten, dass Openresty den hohen Speicherverbrauch verursacht, haben wir alle Lua-Teile mit einem extrahiert. auth_requestJetzt haben wir ein Nginx, das zur Authentifizierung auf Openresty zurückgreift.
Bei gleicher Anzahl an Hosts und SSL-Zertifikaten haben wir jetzt einen deutlich geringeren Speicherverbrauch (~150 MB pro Worker statt 6 GB). Auch OpenResty verbraucht nur eine vernachlässigbare Menge an Speicher. Es scheint also ein Problem mit OpenResty in Kombination mit anderen Teilen unserer Konfiguration gegeben zu haben.
Dies beantwortet zwar nicht genau die ursprüngliche Frage, stellt aber für uns und hoffentlich auch für alle anderen, die auf dieses Problem stoßen, eine nützliche Problemumgehung dar.