Wie behebe ich Probleme mit hoher Latenz auf meinem Application Load Balancer in Elastic Load Balancing?

Kurzbeschreibung

Im Folgenden werden die Ursachen für eine hohe Latenz auf einem Application Load Balancer aufgezählt:

• Probleme mit der Netzwerkkonnektivität oder Überlastung
• Hohe Speicherauslastung (RAM) auf Backend-Instances
• Hohe CPU-Auslastung auf Backend-Instances
• Falsche Webserverkonfiguration auf Backend-Instances
• Probleme mit Webanwendungsabhängigkeiten, die auf Backend-Instances ausgeführt werden
• Große geografische Entfernung zwischen Clients oder On-Premises-Zielen und dem Application Load Balancer

Lösung

Gehe wie folgt vor, um Probleme mit hoher Latenz auf dem Application Load Balancer zu beheben:

• Suche nach Problemen mit der Netzwerkverbindung. Weitere Informationen findest du unter Problembehandlung bei Application Load Balancern.

• Messe die erste Byte-Antwort und nach einer langsamen DNS-Auflösung zu suchen, die zu Latenz führen kann:

  curl -kso /dev/null -w "\n===============\n
  | DNS lookup: %{time_namelookup}\n
  | Connect: %{time_connect}\n
  | App connect: %{time_appconnect}\n
  | Pre-transfer: %{time_pretransfer}\n
  | Start transfer: %{time_starttransfer}\n
  | Total: %{time_total}\n
  | HTTP Code: %{http_code}\n===============\n" https://example.com/

  Beispielausgabe:

  ===============
  | DNS lookup: 0.002346
  | Connect: 0.003080
  | App connect: 0.008422
  | Pre-transfer: 0.008587
  | Start transfer: 0.050238
  | Total: 0.057486
  | HTTP Code: 200
  ===============

  Hinweis: Um herauszufinden, was die Latenz verursacht, führe den vorherigen Schritt mit dem Application Load Balancer aus. Führe den Schritt dann erneut durch und umgehe den Application Load Balancer. Weitere Informationen findest du unter curl man page auf der curl-Website.

• Überprüfe die Statistik Durchschnitt der Amazon CloudWatch TargetResponseTime-Metrik für den Application Load Balancer. Wenn der Wert hoch ist, liegt ein Problem mit den Backend-Instances oder den Anwendungsabhängigkeitsservern vor. Weitere Informationen findest du unter Wie behebe ich einen Anstieg der TargetResponseTime-Metrik für einen Application Load Balancer?

• Um die Backend-Instances mit hoher Latenz zu identifizieren, überprüfe die Zugriffsprotokolleinträge des Application Load Balancers.

• Um Backend-Instances mit Latenzproblemen zu identifizieren, überprüfe die target_processing_time für einen längeren Zeitraum als normal.

• Um Probleme mit dem Application Load Balancer zu bestätigen, überprüfe die Felder request_processing_time und response_processing_time für längere Zeiträume als gewöhnlich.

  Beispiel für einen Protokolleintrag:

  http 2024-04-01T22:23:00.765170Z app/example-loadbalancer/50dc6c495c0c9188
  192.168.131.39:2817 10.0.0.1:80 0.001 12.401 0.001 200 200 34 366
  "GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
  arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/example-targets/73e2d6bc24d8a067
  "Root=1-58337262-36d228ad5d99923122bbe354" "-" "-"
  0 2024-04-01T22:22:48.364000Z "forward" "-" "-" "10.0.0.1:80" "200" "-" "-"

  Hinweis: Der vorhergehende Beispielprotokolleintrag zeigt, dass request_processing_time 0,001 ist, target_processing_time 12,401 ist und die response_processing_time 0,001 ist. Der Wert target_processing_time zeigt einen längeren Zeitraum als gewöhnlich an und zeigt, dass das Application Load Balancer-Ziel Latenz verursacht hat. Weitere Informationen findest du unter Syntax.

• Um eine hohe CPU-Auslastung oder Spitzen bei der CPU-Auslastung zu identifizieren, überprüfe die CloudWatch CPUUtilization-Metrik der Backend-Instances. Um eine hohe CPU-Auslastung zu beheben, solltest du die Instance auf einen größeren Instance-Typ aufrüsten.

• Führe den folgenden Befehl aus, um die Apache-Prozesse im Backend zu überprüfen und nach Speicherproblemen zu suchen:

  watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

  Beispielausgabe:

  Every 1.0s: echo -;n 'Apache Processes: ' && ps -;C apache2 -;no-headers | wc -1 && free -;m
  Apache Processes: 27
            total     used     free     shared     buffers     cached
  Mem:      8204      7445     758      0          385         4567
  -/+ buffers/cache:  2402     5801
  Swap:     16383     189      16194

• Um zu überprüfen wie viele Anfragen die Instance gleichzeitig bearbeiten kann, sieh dir die MaxClient-Einstellung für die Webserver auf den Backend-Instances an. Wenn die Instance über eine angemessene Menge an Speicher und CPU-Auslastung verfügt und dennoch eine hohe Latenz aufweist, erhöhe den MaxClient-Wert.

• Vergleiche die Anzahl der Prozesse, die Apache generiert (httpd), mit dem MaxClient-Wert. Wenn die Anzahl der Apache-Prozesse häufig den MaxClient-Wert erreicht, erhöhe den MaxClient-Wert.

  Beispielbefehl:

  [root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15

  Beispielausgabe:

  <IfModule prefork.c>StartServers         10
  MinSpareServers      5
  MaxSpareServers      10
  ServerLimit          15
  MaxClients           15
  MaxRequestsPerChild  4000
  </IfModule>

Backend-Abhängigkeiten überprüfen

Suche nach Abhängigkeiten auf den Backend-Instances, die möglicherweise zu Latenzproblemen führen können. Zu den Beispielabhängigkeiten gehören Amazon Simple Storage Service (Amazon S3)-Buckets, Network Address Translation (NAT)-Instances oder Proxyserver sowie Remote-Web-Dienste.

Linux-Tools verwenden, um Leistungsengpässe zu identifizieren

Um Leistungsengpässe auf dem Server zu identifizieren, verwende die folgenden Linux-Befehle:

• Führe den Uptime-Befehl aus, um zu überprüfen, ob aufgrund von Ressourcenkonflikten die durchschnittliche Systemlast hoch ist. Die Ausgabe zeigt dir die Durchschnittswerte der Systemlast, d. h. die Anzahl der Aufgaben, die auf ihre Ausführung warten oder bei I/O blockiert sind. 
• Der Befehl mpstat -P ALL 1 zeigt dir eine Aufschlüsselung der CPU-Auslastung für jeden Kern. Führe den Befehl aus, um eine ungleichmäßige Nutzung zu ermitteln, z. B. einen einzelnen Kern, der die meiste Arbeit in einer Single-Thread-Anwendung erledigt.
• Führe den Befehl pidstat 1 aus, um ressourcenintensive Prozesse und Muster im Laufe der Zeit zu identifizieren. Die Ausgabe zeigt die CPU-Auslastung in Echtzeit pro Prozess.
• Führe den Befehl dmesg | tail aus, um aktuelle Ereignisse auf Systemebene zu identifizieren, die sich auf die Leistung auswirken könnten. Die Ausgabe zeigt die letzten 10 Systemnachrichten.
• Führe den Befehl iostat -xz 1 aus, um hohe Lese- oder Schreibvorgänge oder eine langsame Festplattenleistung zu identifizieren. Die Ausgabe zeigt die I/O-Metriken und die Nutzung der Festplatte. 
• Führe den Befehl free -m aus, um den verfügbaren Systemspeicher anzuzeigen. Wenn der verfügbare Speicher knapp ist, ist das System möglicherweise auf Swap angewiesen, was die Festplatten-I/O und die Latenz erhöht.
• Führe den Befehl sar -n DEV 1 tool aus, um die Bandbreitensättigung zu ermitteln. Die Ausgabe zeigt den Durchsatz der Netzwerkschnittstelle, der empfangenen (RxKB/s) und übertragenen (TxKb/s) Datenverkehr umfasst.
• Führe sar -n TCP, ETCP 1 aus, um die folgenden wichtigen TCP-Metriken anzuzeigen, anhand derer du Verbindungsprobleme ermitteln kannst:
  Die active/s-Metrik ist die Anzahl der lokal initiierten TCP-Verbindungen pro Sekunde.
  Die passiv/s-Metrik ist die Anzahl der remote initiierten TCP-Verbindungen pro Sekunde.
  Die retrans/s-Metrik ist die Anzahl der TCP-Neuübertragungen pro Sekunde. Wenn diese Metrik hoch ist, kommt es möglicherweise zu Paketverlust oder einer Überlastung.
• Führe den Befehl iftop aus, um zu ermitteln, was die meiste Bandbreite im Netzwerk beansprucht. Die Ausgabe zeigt die aktive Bandbreitennutzung für jede Verbindung in Echtzeit.
• Der Befehl niftop ist eine Variante von iftop, die möglicherweise über Drittanbieter-Repositorys auf Red Hat Enterprise Linux (RHEL) und Debian-basierten Distributionen verfügbar ist. Wenn iftop nicht auf dem System vorinstalliert ist, verwende niftop.

Hinweis: Abhängig von der Linux-Distribution musst du möglicherweise einige der oben genannten Befehle manuell installieren.