Wie kann ich Probleme mit hoher Latenz auf meinem Application Load Balancer beheben?

Kurzbeschreibung

Zu den möglichen Ursachen für eine hohe Latenz auf einem Application Load Balancer gehören:

• Probleme mit der Netzwerkverbindung
• Hohe Speicherauslastung (RAM) auf Backend-Instances
• Hohe CPU-Auslastung auf Backend-Instances
• Falsche Webserverkonfiguration auf Backend-Instances
• Probleme mit Abhängigkeiten von Webanwendungen, die auf Backend-Instances ausgeführt werden, z. B. externen Datenbanken oder Amazon Simple Storage Service (Amazon S3)-Buckets

Behebung

1.    Suchen Sie mithilfe der Schritte zur Fehlerbehebung unter Problembehandlung bei Ihren Application Load Balancers nach Netzwerkverbindungsproblemen.

2.    Verwenden Sie das Curl-Tool, um die Antwort auf das erste Byte zu messen und zu überprüfen, ob eine langsame DNS-Auflösung zur Latenz beiträgt.

curl -kso /dev/null https://www.example.com -w "==============\n\n
| dnslookup: %{time_namelookup}\n
| connect: %{time_connect}\n
| appconnect: %{time_appconnect}\n
| pretransfer: %{time_pretransfer}\n
| starttransfer: %{time_starttransfer}\n
| total: %{time_total}\n
| size: %{size_download}\n
| HTTPCode=%{http_code}\n\n"

Beispiel für eine Ausgabe:

 | dnslookup: 0.005330
 | connect: 0.006682
 | appconnect: 0.026540
 | pretransfer: 0.026636
 | starttransfer: 0.076980
 | total: 0.077111
 | size: 12130
 | HTTPCode=200

Führen Sie diese Tests mit dem Application Load Balancer durch. Führen Sie dann die Tests durch und umgehen Sie dabei den Application Load Balancer zu den Zielen. Dieser Ansatz hilft, die Komponente zu isolieren, die Latenz verursacht. Weitere Informationen zu Curl-Funktionen finden Sie unter So verwenden Sie Curl-Funktionen.

3.    Überprüfen Sie die Durchschnittsstatistik der Amazon CloudWatch TargetResponseTime-Metrik für Ihren Application Load Balancer. Wenn der Wert hoch ist, liegt wahrscheinlich ein Problem mit den Backend-Instances oder den Anwendungsabhängigkeitsservern vor.

4.    Stellen Sie fest, bei welchen Backend-Instances eine hohe Latenz auftritt, indem Sie die Zugriffsprotokolleinträge für Ihren Application Load Balancer überprüfen. Überprüfen Sie target_processing_time, um Backend-Instances mit Latenzproblemen zu finden. Überprüfen Sie außerdem die Felder request_processing_time und response_processing_time, um alle Probleme mit dem Application Load Balancer zu überprüfen.

5. Überprüfen Sie die CloudWatch-Metrik zur CPU-Auslastung Ihrer Backend-Instances. Achten Sie auf eine hohe CPU-Auslastung oder Spitzen bei der CPU-Auslastung. Für eine hohe CPU-Auslastung sollten Sie erwägen, Ihre Instances auf einen größeren Instance-Typ aufzurüsten.

6.    Suchen Sie nach Speicherproblemen, indem Sie die Apache-Prozesse auf Ihren Backend-Instances überprüfen.

Beispielbefehl:

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

Beispiel für eine Ausgabe:

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

7.    Überprüfen Sie die MaxClient-Einstellung für die Webserver auf Ihren Backend-Instances. Diese Einstellung definiert, wie viele Anfragen die Instance gleichzeitig bearbeiten kann. Bei Instances mit entsprechender Speicher- und CPU-Auslastung, bei denen eine hohe Latenz auftritt, sollten Sie erwägen, den MaxClient-Wert zu erhöhen.

Vergleichen Sie die Anzahl der von Apache (httpd) generierten Prozesse mit der MaxClient-Einstellung. Wenn die Anzahl der Apache-Prozesse häufig den MaxClient-Wert erreicht, sollten Sie erwägen, den Wert zu erhöhen.

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

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

8.    Suchen Sie nach Abhängigkeiten Ihrer Backend-Instances, die möglicherweise zu Latenzproblemen führen. Abhängigkeiten können gemeinsam genutzte Datenbanken oder externe Ressourcen (wie Amazon S3-Buckets) beinhalten. Abhängigkeiten können auch externe Ressourcenverbindungen wie NAT-Instances (Network Address Translation), Remote-Webdienste oder Proxyserver beinhalten.

9.    Verwenden Sie die folgenden Linux-Tools, um Leistungsengpässe auf dem Server zu identifizieren.

uptime — Zeigt Durchschnittswerte der Auslastung an, anhand derer die Anzahl der Aufgaben (Prozesse) ermittelt werden kann, die auf ihre Ausführung warten. Auf Linux-Systemen beinhaltet diese Zahl Prozesse, die darauf warten, auf der CPU ausgeführt zu werden, sowie Prozesse, die durch unterbrechungsfreie I/O blockiert sind (normalerweise Festplatten-I/O). Diese Daten bieten einen umfassenden Überblick über die Ressourcenlast (oder den Bedarf), der mit anderen Tools interpretiert werden muss. Wenn die durchschnittliche Linux-Auslastung steigt, besteht ein höherer Bedarf an Ressourcen. Um festzustellen, welche Ressourcen stärker nachgefragt werden, müssen Sie andere Metriken verwenden. Für CPUs können Sie beispielsweise mpstat -P ALL 1 verwenden, um die Auslastung pro CPU zu messen, oder **top **oder pidstat 1, um die CPU-Auslastung pro Prozess zu messen.

mpstat -P ALL 1— Zeigt die CPU-Zeitaufschlüsselung pro CPU an, anhand derer Sie nach einem Ungleichgewicht suchen können. Eine einzelne Hot-CPU könnte ein Hinweis auf eine Single-Thread-Anwendung sein.

pidstat 1— Zeigt die CPU-Auslastung pro Prozess an und gibt eine fortlaufende Zusammenfassung aus, die nützlich ist, um Muster im Laufe der Zeit zu beobachten.

dmesg | tail— Zeigt die letzten 10 Systemmeldungen an, falls es welche gibt. Suchen Sie nach Fehlern, die zu Leistungsproblemen führen können.

iostat -xz 1— Zeigt die Arbeitslast für Blockgeräte (Festplatten) und die daraus resultierende Leistung an.

free -m— Zeigt die Menge an freiem Speicher an. Stellen Sie sicher, dass diese Zahlen nicht nahe Null liegen, da dies zu höheren Festplatten-I/O (überprüfen Sie mit iostat) und zu einer verringerten Leistung führen kann.

sar -n DEV 1— Zeigt den Netzwerkschnittstellendurchsatz (RxKB/s und TxKB/s) als Maß für die Arbeitslast an. Prüfen Sie, ob irgendwelche Limits erreicht wurden.

sar -n TCP, ETCP 1— Zeigt wichtige TCP-Metriken an, darunter: aktiv/s (Anzahl der lokal initiierten TCP-Verbindungen pro Sekunde), passiv/s (Anzahl der remote initiierten TCP-Verbindungen pro Sekunde) und retrans/s (Anzahl der TCP-Neuübertragungen pro Sekunde).

iftop— Zeigt die Verbindungen zwischen Ihrem Server und einer Remote-IP-Adresse an, die die meiste Bandbreite verbrauchen. n iftop ist in einem Paket mit dem gleichen Namen auf Red Hat- und Debian-basierten Distributionen verfügbar. Bei Red Hat-basierten Distributionen finden Sie jedoch möglicherweise stattdessen ein n iftop in einem Repository eines Drittanbieters.

---