Identifizierung und Behebung von Nginx-Leistungsengpässen: Ein Leitfaden zur Fehlerbehebung

Nginx-Leistungsprobleme zeigen sich meist auf einfache Weise: Seiten laden langsam, API-Aufrufe beginnen mit Timeouts, die CPU-Auslastung steigt oder Benutzer sehen 502- und 504-Fehler. Die Schwierigkeit besteht darin, herauszufinden, ob Nginx der Engpass ist oder ob es nur der erste Dienst ist, der laut genug klagt.

Wenn ich Nginx-Probleme behebe, versuche ich nicht, mit der Änderung von Direktiven zu beginnen. Ich stelle zunächst ein paar einfache Fragen. Ist die Latenz für alle Routen gestiegen oder nur für Routen, die einen bestimmten Upstream treffen? Sind statische Dateien auch langsam? Traten die Fehler nach einem Deployment, einem Traffic-Spike, einer Zertifikatsänderung oder einer Logging-Änderung auf? Dieser Kontext spart in der Regel mehr Zeit, als einen Tuning-Block aus einem alten Beitrag zu kopieren.

Grundlegendes zu Nginx-Leistungsmetriken

Bevor Sie mit der Fehlerbehebung beginnen, ist es wichtig zu verstehen, was einen Leistungsengpass ausmacht und welche Metriken Schlüsselindikatoren sind. Ein Engpass tritt auf, wenn eine Komponente in Ihrem System die Gesamtkapazität oder -geschwindigkeit begrenzt. Bei Nginx hängt dies oft mit der Fähigkeit zusammen, Anfragen zu verarbeiten, Verbindungen zu verwalten oder Inhalte effizient bereitzustellen.

Zu den wichtigsten zu überwachenden Metriken gehören:

• Aktive Verbindungen: Die Anzahl der Client-Verbindungen, die derzeit von Nginx verarbeitet werden.
• Anfragen pro Sekunde (RPS): Die Rate, mit der Nginx Anfragen bedient.
• Anfragelatenz: Die Zeit, die Nginx benötigt, um auf eine Client-Anfrage zu antworten.
• CPU-Auslastung: Der Prozentsatz der CPU-Ressourcen, die von Nginx-Worker-Prozessen verbraucht werden.
• Speicherauslastung: Die Menge an RAM, die von Nginx-Prozessen verwendet wird.
• Netzwerk-I/O: Die Rate der Datenübertragung in den und aus dem Nginx-Server.
• Festplatten-I/O: Relevant, wenn Nginx statische Dateien direkt bereitstellt oder umfangreich protokolliert.

Integrierte Nginx-Tools zur Diagnose

Nginx bietet mehrere Funktionen zur Überwachung des Betriebsstatus und zur Erfassung von Leistungsdaten.

Verwendung des stub_status-Moduls

Das stub_status-Modul liefert grundlegende, aber wichtige Informationen über den aktuellen Zustand von Nginx. Es ist ein ausgezeichneter erster Anlaufpunkt für einen schnellen Überblick über die Serveraktivität.

Aktivieren von stub_status

Um stub_status zu aktivieren, fügen Sie den folgenden Konfigurationsblock zu Ihrer nginx.conf hinzu (normalerweise innerhalb des server-Blocks für Ihren Überwachungsendpunkt):

server {
    listen 80;
    server_name monitoring.example.com;

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1; # Zugriff nur von localhost erlauben
        deny all;
    }
}

Nachdem Sie die Konfiguration geändert haben, laden Sie Nginx neu:

sudo nginx -t # Konfiguration testen
sudo nginx -s reload # Nginx neu laden

Interpretation der stub_status-Ausgabe

Rufen Sie die Statusseite auf (z. B. http://localhost/nginx_status), um eine Ausgabe ähnlich dieser zu sehen:

Active connections: 291
server accepts handled requests
 1162447 1162447 4496426
Reading: 6 Writing: 17 Waiting: 268

Hier ist die Bedeutung jeder Metrik:

• Active connections: Die aktuelle Anzahl aktiver Client-Verbindungen, einschließlich Reading-, Writing- und Waiting-Verbindungen.
• accepts: Die Gesamtzahl der von Nginx akzeptierten Verbindungen.
• handled: Die Gesamtzahl der von Nginx bearbeiteten Verbindungen. Idealerweise sollten accepts und handled gleich sein. Wenn handled deutlich niedriger ist, könnte dies auf Ressourcenbeschränkungen hindeuten (z. B. worker_connections-Limit).
• requests: Die Gesamtzahl der von Nginx verarbeiteten Client-Anfragen.
• Reading: Die Anzahl der Verbindungen, bei denen Nginx gerade den Anforderungsheader liest.
• Writing: Die Anzahl der Verbindungen, bei denen Nginx gerade die Antwort an den Client zurückschreibt.
• Waiting: Die Anzahl der untätigen Client-Verbindungen, die auf eine Anfrage warten (z. B. keep-alive-Verbindungen). Eine hohe Anzahl kann hier auf eine effiziente keep-alive-Nutzung hindeuten, aber auch darauf, dass Worker-Prozesse durch Warten gebunden sind, was ein Problem darstellen kann, wenn die aktiven Verbindungen niedrig und die Ressourcen knapp sind.

Nutzung der Nginx Plus API für erweiterte Metriken

Für Nginx Plus-Benutzer bietet die Nginx Plus API eine detailliertere, Echtzeit-JSON-Schnittstelle zur Überwachung. Diese API bietet granulare Metriken für Zonen, Server, Upstreams, Caches und mehr, was sie für eine eingehende Leistungsanalyse und die Integration in Überwachungs-Dashboards unverzichtbar macht.

Aktivieren der Nginx Plus API

Konfigurieren Sie einen Speicherort für die API in Ihrer Nginx Plus-Konfiguration:

http {
    server {
        listen 8080;

        location /api {
            api write=on;
            allow 127.0.0.1; # Zugriff aus Sicherheitsgründen einschränken
            deny all;
        }

        location /api.html {
            root /usr/share/nginx/html;
        }
    }
}

Laden Sie Nginx neu und rufen Sie http://localhost:8080/api auf, um die JSON-Ausgabe anzuzeigen. Diese API liefert umfangreiche Daten, einschließlich detaillierter Verbindungsstatistiken, Anforderungsverarbeitungszeiten, Upstream-Status und Cache-Leistung, was eine viel feinere Fehlerbehebung als stub_status ermöglicht.

Nginx Access- und Error-Logs

Nginx-Logs sind eine Fundgrube an Informationen für die Leistungsfehlerbehebung. Sie zeichnen jede Anfrage und alle aufgetretenen Fehler auf.

Konfigurieren detaillierter Protokollierung

Sie können Ihr log_format anpassen, um nützliche Leistungsmetriken wie die Anforderungsverarbeitungszeit ($request_time) und die Upstream-Antwortzeit ($upstream_response_time) aufzunehmen.

http {
    log_format perf_log '$remote_addr - $remote_user [$time_local] "$request" ' 
                        '$status $body_bytes_sent "$http_referer" ' 
                        '"$http_user_agent" "$http_x_forwarded_for" ' 
                        'request_time:$request_time upstream_response_time:$upstream_response_time ' 
                        'upstream_addr:$upstream_addr';

    access_log /var/log/nginx/access.log perf_log;
    error_log /var/log/nginx/error.log warn;

    # Beispiel zum Protokollieren von Anfragen, die langsamer als ein Schwellenwert sind
    # Dies ist etwas fortgeschrittener und erfordert möglicherweise ein benutzerdefiniertes Modul oder ein separates Tool zum Parsen.
    # Oft ist es einfacher, das Haupt-Access-Log nach langsamen Anfragen zu durchsuchen.
}

Identifizieren langsamer Anfragen und Fehler

• Langsame Anfragen: Verwenden Sie Tools wie grep oder awk, um Ihre Access-Logs nach Anfragen zu durchsuchen, die einen bestimmten $request_time- oder $upstream_response_time-Schwellenwert überschreiten. Dies hilft, problematische Anwendungen oder externe Dienste zu identifizieren.

  awk 'match($0, /request_time:([0-9.]+)/, m) && m[1] > 1.0 {print $0}' /var/log/nginx/access.log
  

  Dies vermeidet die Abhängigkeit von einer festen Log-Feldnummer, die bricht, sobald der Anforderungspfad, der User-Agent oder der Referrer Leerzeichen enthält.
• Fehler: Überwachen Sie error.log auf kritische Probleme wie "upstream timed out", "no live upstreams" oder "too many open files". Diese Fehler weisen direkt auf Backend-Probleme oder Nginx-Ressourcenbeschränkungen hin.

Externe Systemüberwachungstools

Die Nginx-Leistung ist oft an die Ressourcen des zugrunde liegenden Servers gebunden. Die Systemüberwachung auf Systemebene liefert entscheidenden Kontext.

• CPU-Auslastung (top, htop, mpstat): Eine hohe CPU-Auslastung durch Nginx-Worker-Prozesse kann auf eine komplexe Konfiguration (Regex, SSL-Handshakes), ineffizienten Code oder einfach eine hohe Last hindeuten.

  top -c # Zeigt Prozesse sortiert nach CPU-Auslastung
  

• Speicherauslastung (free -h, htop): Übermäßiger Speicherverbrauch könnte auf große Puffergrößen (proxy_buffers), Speicherlecks oder eine ungewöhnlich hohe Anzahl aktiver Verbindungen hindeuten.

  free -h # Zeigt die Speicherauslastung in menschenlesbarem Format an
  

• Festplatten-I/O (iostat, iotop): Relevant, wenn Nginx stark statische Inhalte bereitstellt oder umfangreich protokolliert. Hohe Festplatten-I/O könnte einen Engpass im Speicher oder zu viel Protokollierung bedeuten.

  iostat -x 1 10 # Zeigt erweiterte Festplattenstatistiken jede Sekunde für 10 Mal an
  

• Netzwerk-I/O (netstat, ss, iftop): Überwachen Sie den Netzwerkverkehr auf Sättigung oder übermäßige Neuübertragungen, was auf Netzwerkengpässe oder Probleme zwischen Nginx und Clients/Upstreams hindeuten könnte.

  netstat -antp | grep nginx # Nginx-Verbindungen anzeigen
  

Häufige Nginx-Leistungsengpässe und deren Behebung

Mit den Überwachungsdaten betrachten wir nun häufige Probleme und deren Behebung.

1. Hohe CPU-Auslastung

Symptome: top zeigt, dass Nginx-Worker-Prozesse einen großen Prozentsatz der CPU verbrauchen, selbst bei moderater Last.

Ursachen:

• Zu wenige Worker-Prozesse für Multi-Core-CPUs: Nginx nutzt möglicherweise nicht alle verfügbaren Kerne.
• Komplexe if-Anweisungen oder reguläre Ausdrücke: Übermäßig komplexe Regex oder viele if-Anweisungen in der Konfiguration können CPU-intensiv sein.
• Ineffiziente SSL/TLS-Konfiguration: Verwendung schwacher Ciphers, die mehr CPU erfordern, oder keine Nutzung von Hardwarebeschleunigung, falls verfügbar.
• Übermäßige Protokollierung: Zu viele Daten auf die Festplatte schreiben, insbesondere mit komplexen log_format-Regeln.
• TLS-, Komprimierungs- oder Anforderungsverarbeitungs-Overhead: Teure TLS-Handshakes, hohe Komprimierungsstufen, schwere Rewrite-Regeln oder sehr große Anforderungsheader können die CPU-Auslastung in die Höhe treiben.

Behebungen:

• Optimieren Sie worker_processes: Setzen Sie worker_processes auto; (empfohlen) oder auf die Anzahl der CPU-Kerne. Jeder Worker-Prozess ist single-threaded und kann einen CPU-Kern voll ausnutzen.

  worker_processes auto;
  

• Vereinfachen Sie die Konfiguration: Überprüfen Sie if-Anweisungen und Regex. Erwägen Sie die Verwendung von map-Direktiven oder try_files für einfachere Logik.
• Optimieren Sie SSL/TLS: Verwenden Sie moderne TLS-Einstellungen und aktivieren Sie ssl_session_cache und ssl_session_timeout, wo dies sinnvoll ist, um wiederholte Handshake-Arbeiten zu reduzieren.
• Kontrollieren Sie die Protokollierung: Verwenden Sie gepufferte Access-Logs oder deaktivieren Sie Access-Logs für laute statische Assets, wenn Sie dort keine Pro-Anfrage-Aufzeichnungen benötigen.
• Untersuchen Sie das Backend: Wenn Nginx wartet, liegt der Engpass im Upstream. Optimieren Sie die Backend-Anwendung.

2. Langsame Antwortzeiten

Symptome: Hohe $request_time oder $upstream_response_time in Logs; Seiten laden langsam.

Ursachen:

• Probleme mit dem Upstream (Backend)-Server: Die häufigste Ursache. Der Anwendungsserver ist langsam bei der Generierung von Antworten.
• Große Dateiübertragungen ohne ordnungsgemäße Optimierung: Bereitstellung großer statischer Dateien ohne sendfile oder gzip.
• Netzwerklatenz: Langsames Netzwerk zwischen Client und Nginx oder Nginx und Upstream.
• Fehlendes Caching: Wiederholtes Abrufen dynamischer Inhalte.

Behebungen:

• Optimieren Sie Upstream-Health-Checks und Timeouts: Konfigurieren Sie proxy_read_timeout, proxy_connect_timeout und proxy_send_timeout. Implementieren Sie Health-Checks für Upstream-Server.

  location / {
      proxy_pass http://backend_app;
      proxy_read_timeout 90s; # Nach Bedarf anpassen
      proxy_connect_timeout 5s;
  }
  

• Aktivieren Sie die gzip-Komprimierung: Für textbasierte Inhalte reduziert gzip die Übertragungsgröße erheblich.

  gzip on;
  gzip_comp_level 5;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
  

• Aktivieren Sie sendfile und tcp_nodelay: Für eine effiziente Bereitstellung statischer Dateien.

  sendfile on;
  tcp_nodelay on;
  

• Implementieren Sie Caching: Verwenden Sie proxy_cache für dynamische Inhalte oder setzen Sie expires-Header für statische Assets.

  # Beispiel für statische Assets
  location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
      expires 30d;
      log_not_found off;
  }
  

3. Verbindungsfehler / Maximale Verbindungen erreicht

Symptome: Clients erhalten Verbindungsfehler, 502- oder 504-Antworten oder zeitweilige Timeouts. stub_status zeigt möglicherweise, dass akzeptierte Verbindungen schnell ansteigen, und das Fehlerprotokoll erwähnt möglicherweise worker_connections are not enough, too many open files oder Upstream-Verbindungsfehler.

Ursachen:

• worker_connections-Limit erreicht: Nginx kann keine neuen Verbindungen akzeptieren.
• Zu viele offene Dateien (ulimit): Das Betriebssystemlimit für Dateideskriptoren ist erreicht.
• Backend-Sättigung: Upstream-Server sind überlastet und akzeptieren keine Verbindungen.
• DDoS oder ungewöhnlich hoher legitimer Traffic.

Behebungen:

• Erhöhen Sie worker_connections: Setzen Sie diese Direktive auf einen hohen Wert (z. B. 10240 oder höher) innerhalb des events-Blocks. Dies ist die maximale Anzahl von Verbindungen pro Worker-Prozess.

  events {
      worker_connections 10240;
  }
  

• Passen Sie die Dateideskriptor-Limits an: Erhöhen Sie das Limit für offene Dateien des Betriebssystems. Fügen Sie worker_rlimit_nofile 65535; zur nginx.conf hinzu, falls angemessen, und setzen Sie das Dienstlimit über systemd mit LimitNOFILE=65535 auf den meisten modernen Linux-Distributionen.
• Optimieren Sie keepalive_timeout: Lange keep-alive-Timeouts können Worker-Prozesse unnötig binden, wenn Clients Verbindungen nicht wiederverwenden. Verkürzen Sie es, wenn Waiting-Verbindungen hoch und requests niedrig sind.

  keepalive_timeout 15s; # Standard ist 75s
  

• Implementieren Sie Lastverteilung und Skalierung: Verteilen Sie den Datenverkehr auf mehrere Backend-Server. Erwägen Sie die Lastverteilungsfähigkeiten von Nginx (Round-Robin, Least-Connected, IP-Hash).
• Ratenbegrenzung: Verwenden Sie die Module limit_req oder limit_conn, um Ihren Server vor übermäßigen Anfragen oder Verbindungen von einzelnen Clients zu schützen.

4. Hohe Speicherauslastung

Symptome: Nginx-Worker-Prozesse verbrauchen erheblichen RAM; der Server könnte übermäßig auslagern.

Ursachen:

• Große Puffergrößen: proxy_buffers, client_body_buffer_size, fastcgi_buffers sind zu hoch konfiguriert.
• Umfangreiches Caching: Große proxy_cache_path-Größen.
• Viele aktive Verbindungen: Jede Verbindung benötigt etwas Speicher.

Behebungen:

• Passen Sie die Puffergrößen an: Erhöhen Sie die Puffergrößen nur, wenn Logs ein echtes Pufferproblem zeigen, z. B. wenn Antwortheader zu groß für den konfigurierten Proxy- oder FastCGI-Puffer sind. 413 Request Entity Too Large wird durch Anforderungskörpergrenzen wie client_max_body_size gesteuert, nicht durch Proxy-Antwortpuffer.

  proxy_buffer_size 4k;
  proxy_buffers 8 8k;
  

• Optimieren Sie das Caching: Verwalten Sie Cache-Größen und Räumungsrichtlinien (proxy_cache_path-Parameter).
• Überprüfen Sie keepalive_timeout: Wie bereits erwähnt, können übermäßig lange keepalive_timeout-Werte Worker-Prozesse und deren zugehörigen Speicher für untätige Verbindungen aktiv halten.

Best Practices für die Nginx-Konfiguration zur Leistungsoptimierung

Über die Behebung spezifischer Probleme hinaus helfen diese allgemeinen Best Practices, eine optimale Nginx-Leistung aufrechtzuerhalten:

• worker_processes auto;: Alle CPU-Kerne nutzen.
• worker_connections: Setzen Sie einen Wert, der der erwarteten Parallelität und den Dateideskriptor-Limits entspricht. 4096 oder 8192 ist ein üblicher Ausgangspunkt für vielbesuchte Server, aber der richtige Wert hängt von der Arbeitslast ab.
• sendfile on;: Für effiziente Bereitstellung statischer Dateien.
• tcp_nodelay on;: Stellt die sofortige Übertragung kleiner Pakete sicher und verbessert die Latenz für interaktive Dienste.
• keepalive_timeout: Passen Sie es basierend auf dem Client-Verhalten an; 15-30 Sekunden sind oft ein guter Kompromiss.
• gzip on;: Aktivieren Sie die Komprimierung für textbasierte Inhalte.
• proxy_buffering on;: Lassen Sie die Pufferung im Allgemeinen eingeschaltet. Sie ermöglicht es Nginx, die Antwort vom Upstream-Server auf die Festplatte zu spulen (falls erforderlich) und sie so schnell wie möglich an den Client zu senden, wodurch der Upstream freigegeben wird. Deaktivieren Sie sie nur, wenn Echtzeit-Niedriglatenz-Streaming absolut kritisch ist und Sie die Auswirkungen verstehen.
• expires-Header: Zwischenspeichern Sie statische Inhalte aggressiv auf der Client-Seite.
• Minimieren Sie if-Anweisungen und Regex: Entscheiden Sie sich für map-Direktiven oder try_files für eine bessere Leistung.
• Verwenden Sie access_log off; für statische Dateien: Reduziert die Festplatten-I/O für häufig aufgerufene statische Assets, wenn die Protokollierung nicht unbedingt erforderlich ist.
• HTTP/2: Aktivieren Sie HTTP/2 für moderne Browser, um Multiplexing und Header-Komprimierung über HTTPS zu verbessern.

  listen 443 ssl http2;
  

Workflow und Strategie zur Fehlerbehebung

Wenn Sie mit einem Leistungsproblem konfrontiert sind, gehen Sie strukturiert vor:

1. Definieren Sie eine Basislinie: Verstehen Sie die normalen Betriebsmetriken (CPU, Speicher, Verbindungen, RPS, Latenz) während gesunder Perioden.
2. Überwachen Sie Symptome: Identifizieren Sie die spezifischen Symptome (z. B. hohe CPU, langsame Anfragen, Verbindungsfehler) und verwenden Sie Tools (stub_status, Logs, top), um sie zu bestätigen.
3. Stellen Sie eine Hypothese auf: Formulieren Sie basierend auf den Symptomen eine Hypothese über die Grundursache (z. B. "Hohe CPU ist auf ineffiziente Regex zurückzuführen").
4. Testen und analysieren Sie: Implementieren Sie eine Änderung (z. B. vereinfachen Sie Regex) und überwachen Sie deren Auswirkungen auf die Metriken. Analysieren Sie neue Logeinträge oder die stub_status-Ausgabe.
5. Wiederholen Sie den Vorgang: Wenn das Problem weiterhin besteht, verfeinern Sie Ihre Hypothese und wiederholen Sie den Vorgang.
6. Dokumentieren Sie: Halten Sie Änderungen und deren Auswirkungen für zukünftige Referenzen fest.

Die besten Nginx-Leistungsbehebungen sind in der Regel langweilig: Beweisen Sie, wo die Verzögerung liegt, ändern Sie eine Sache und beobachten Sie danach dieselbe Metrik. Wenn $upstream_response_time hoch ist, optimieren Sie den App-Pfad, bevor Sie Nginx die Schuld geben. Wenn statische Dateien langsam sind, während die Upstream-Zeit leer ist, überprüfen Sie die Einstellungen für Festplatte, Netzwerk, Komprimierung und statische Dateien. Wenn Fehler Dateideskriptoren oder Worker-Verbindungen erwähnen, beheben Sie diese Limits als Paar. Diese Gewohnheit hält die Fehlerbehebung auf Beweisen und nicht auf Folklore gestützt.