Mir ist ein seltsames Verhalten bei dem Setup aufgefallen, das ich auf AWS (Region eu-south-1) erstellt habe, um die Migration von unserem aktuellen Anbieter zu evaluieren. Ich möchte 1-n EC2-Instanzen bereitstellen, die Webanforderungen über Apache bedienen und Dateien bereitstellen, die auf einem gemeinsamen EFS-Volume gespeichert sind. Ich habe den RDS-Teil, die PHP-Leistung, die ElasticCache-Integration usw. bereits implementiert und getestet. Bei sporadischen Anforderungen ist mir jedoch eine Verzögerung von 5 Sekunden aufgefallen, eine Verzögerung, die sehr deterministisch und zu weit in der Nähe des 5-Sekunden-Werts zu liegen schien. Das EFS-Volume befindet sich im Burst-Modus, die Credits sind hoch (2T) und der Nutzungsprozentsatz ist wirklich niedrig, also sollte dies nicht das Problem sein.
Ich habe das EFS-Volume mit den vorgeschlagenen Optionen gemountet, sowohl mit dem „EFS Mount Helper“ als auch mit dem „NFS Client“, aber es hat sich nichts geändert. Also habe ich versucht, von vorne neu zu starten, indem ich nur den Standard-Apache-Webserver installiert habe (habe es sogar mit Nginx mit ähnlichen Ergebnissen versucht) und das EFS-Volume gemountet und von einer anderen EC2-Instanz aus mit dem folgenden Befehl ein Benchmarking durchgeführt habe:
siege -c 2 -r 20 -b http://35.152.48.17/efs-mount-point/efs-test/logo.png
Bei Ubuntu 18.04 und Ubuntu 20.04 dauert die längste Transaktion immer über 5 Sekunden (5,12 - 5,42 Sekunden). Bei AmiLinux hingegen ist die längste Transaktion schnell genug (0,15 Sekunden). Interessanterweise passiert Folgendes, wenn ich die Anzahl der parallelen Clients von 2 auf 1 reduziere:
siege -c 1 -r 20 -b http://35.152.48.17/efs-mount-point/efs-test/logo.png
die längste Transaktion ist auch unter Ubuntu ok, selbst wenn ich "Siege" für mehrere Wiederholungen laufen lasse:
siege -c 1 -r 10000 -b http://35.152.48.17/efs-mount-point/efs-test/logo.png
Wenn wir jedoch die EFS-Variable auf Ubuntu entfernen und die Dateien vom lokalen EBS bereitstellen, ist die längste Transaktion rasend schnell (wenige Millisekunden), sodass das Problem nur auf EFS mit Ubuntu (sowohl 18.04 als auch 20.04) auftritt. Vielleicht funktionieren die vorgeschlagenen Einbindungsoptionen für AmiLinux, aber es fehlt etwas für Ubuntu-AMIs?
Die Reproduktionsschritte sind so einfach, dass es mir seltsam vorkommt:
- Wählen Sie Ubuntu 18.04 AMI;
- mounten Sie das EFS-Volume (entweder mit dem „EFS Mount Helper“ oder mit dem NFS-Client);
- Installieren Sie Apache und aktualisieren Sie nur das Serververzeichnis.
Irgendein Vorschlag?
Antwort1
Ich habe endlich die Lösung gefunden.
Das Problem tritt nur in den Kerneln „5.4.0-1029-aws“ und „5.4.0-1032-aws“ auf. Das Problem scheint in den Kernelversionen „5.4.0-1034-aws“ und „5.4.0-1035-aws“ behoben zu sein.
Sie müssen also nur den Kernel aktualisieren:
sudo apt-get-update
sudo apt-get install linux-image-5.4.0-1035-aws
Nach dem Neustart sollte der neue Kernel installiert sein. Überprüfen Sie dies mit dem folgenden Befehl:
uname -r
Sie sollten dieses Ergebnis sehen:
5.4.0-1035-aws
Dann sollte es keine Latenz mehr geben.