Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Tipps zur Leistung
Beachten Sie bei der Verwendung von Amazon FSx for Lustre die folgenden Leistungstipps. Informationen zu Servicebeschränkungen finden Sie unter. Servicekontingenten für Amazon FSx for Lustre
-
Durchschnittliche I/O Größe — Da Amazon FSx for Lustre ein Netzwerk-Dateisystem ist, durchläuft jeder Dateivorgang einen Roundtrip zwischen dem Client und Amazon FSx for Lustre, wodurch ein geringer Latenz-Overhead entsteht. Aufgrund dieser Latenz pro Vorgang steigt der Gesamtdurchsatz im Allgemeinen mit steigender I/O Durchschnittsgröße, da sich der Overhead bei einer größeren Datenmenge amortisiert.
-
Anforderungsmodell — Durch die Aktivierung asynchroner Schreibvorgänge in Ihr Dateisystem werden ausstehende Schreibvorgänge auf der Amazon EC2-Instance gepuffert, bevor sie asynchron in Amazon FSx for Lustre geschrieben werden. Asynchrone Schreibvorgänge besitzen in der Regel niedrigere Latenzen. Bei der Ausführung asynchroner Schreibvorgänge verwendet der Kernel zusätzlichen Speicher zum Zwischenspeichern. Ein Dateisystem, das synchrone Schreibvorgänge aktiviert hat, sendet synchrone Anfragen an Amazon FSx for Lustre. Jeder Vorgang durchläuft einen Hin- und Rücklauf zwischen dem Client und Amazon FSx for Lustre.
Anmerkung
Ihr Anforderungsmodell geht hinsichtlich Konsistenz (wenn Sie mehrere Amazon-EC2-Instances verwenden) und Geschwindigkeit Kompromisse ein.
-
Verzeichnisgröße begrenzen — Um eine optimale Metadatenleistung auf Persistent 2 FSx for Lustre-Dateisystemen zu erzielen, beschränken Sie jedes Verzeichnis auf weniger als 100.000 Dateien. Die Begrenzung der Anzahl der Dateien in einem Verzeichnis reduziert die Zeit, die das Dateisystem benötigt, um das übergeordnete Verzeichnis zu sperren.
-
Amazon EC2-Instances — Anwendungen, die eine große Anzahl von Lese- und Schreibvorgängen ausführen, benötigen wahrscheinlich mehr Speicher oder Rechenkapazität als Anwendungen, die dies nicht tun. Wenn Sie Ihre Amazon EC2-Instances für Ihre rechenintensive Arbeitslast starten, wählen Sie Instance-Typen aus, die über die Menge dieser Ressourcen verfügen, die Ihre Anwendung benötigt. Die Leistungsmerkmale von Amazon FSx for Lustre-Dateisystemen hängen nicht von der Verwendung von Amazon EBS-optimierten Instances ab.
-
Empfohlenes Tuning der Client-Instance für optimale Leistung
Für Client-Instanztypen mit einem Arbeitsspeicher von mehr als 64 GiB empfehlen wir die folgende Optimierung:
sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 *number_of_CPUs>Für Client-Instanztypen mit mehr als 64 vCPU-Kernen empfehlen wir die folgende Optimierung:
echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf # reload all kernel modules to apply the above two settings sudo rebootNachdem der Client gemountet ist, muss das folgende Tuning angewendet werden:
sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32 sudo lctl set_param mdc.*.max_rpcs_in_flight=64 sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50Um die Leistung von Directory Listing (ls) zu optimieren, muss das folgende Tuning vorgenommen werden:
sudo lctl set_param llite.*.statahead_max=512 sudo lctl set_param llite.*.statahead_agl=1 if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then sudo lctl set_param llite.*.statahead_xattr=1 else echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning" fi
Beachten Sie,
lctl set_paramdass dieser Fehler bei einem Neustart bekanntermaßen nicht bestehen bleibt. Da diese Parameter nicht dauerhaft von der Clientseite aus gesetzt werden können, wird empfohlen, einen Boot-Cron-Job zu implementieren, um die Konfiguration mit den empfohlenen Einstellungen einzustellen. -
Lastverteilung zwischen OSTs — In einigen Fällen steuert Ihre Arbeitslast nicht den Gesamtdurchsatz, den Ihr Dateisystem bereitstellen kann (200 MBit/s pro TiB Speicher). In diesem Fall können Sie mithilfe von CloudWatch Metriken Fehler beheben, wenn die Leistung durch ein Ungleichgewicht in den Mustern Ihrer Arbeitslast beeinträchtigt wird. I/O Um herauszufinden, ob dies die Ursache ist, sehen Sie sich die CloudWatch Metrik Maximum für Amazon FSx for Lustre an.
In einigen Fällen zeigt diese Statistik eine Auslastung mit einem Durchsatz von 240 Mbit/s oder mehr (die Durchsatzkapazität einer einzelnen Amazon FSx for Lustre-Festplatte mit 1,2 TiB). In solchen Fällen ist Ihre Arbeitslast nicht gleichmäßig auf Ihre Festplatten verteilt. In diesem Fall können Sie den
lfs setstripeBefehl verwenden, um das Striping der Dateien zu ändern, auf die Ihre Arbeitslast am häufigsten zugreift. Um eine optimale Leistung zu erzielen, sollten Sie Dateien mit hohen Durchsatzanforderungen auf alle OSTs verteilen, aus denen Ihr Dateisystem besteht.Wenn Ihre Dateien aus einem Daten-Repository importiert werden, können Sie einen anderen Ansatz wählen, um Ihre Dateien mit hohem Durchsatz gleichmäßig auf Ihre OSTs zu verteilen. Dazu können Sie den
ImportedFileChunkSizeParameter ändern, wenn Sie Ihr nächstes Amazon FSx for Lustre-Dateisystem erstellen.Nehmen wir beispielsweise an, Ihr Workload verwendet ein 7,0-TiB-Dateisystem (das aus 6 x 1,17-TiB-OSTs besteht) und muss einen hohen Durchsatz über 2,4-GiB-Dateien erreichen. In diesem Fall können Sie den
ImportedFileChunkSizeWert(2.4 GiB / 6 OSTs) = 400 MiBso einstellen, dass Ihre Dateien gleichmäßig auf die OSTs Ihres Dateisystems verteilt werden. -
LustreClient für Metadaten-IOPS — Wenn für Ihr Dateisystem eine Metadatenkonfiguration angegeben ist, empfehlen wir Ihnen, einen Lustre 2.15-Client oder einen Lustre 2.12-Client mit einer dieser Betriebssystemversionen zu installieren: Amazon Linux 2023; Amazon Hat/Rocky Linux 2; Red Linux 8.9, 8.10 oder 9.x; CentOS 8.9 oder 8.10; Ubuntu 22+ mit 6.2-, 6.5- oder 6.8-Kernel; oder Ubuntu 20.
Intelligent-Tiering Überlegungen zur Leistung
Im Folgenden finden Sie einige wichtige Überlegungen zur Leistung bei der Arbeit mit Dateisystemen, die die Intelligent-Tiering Speicherklasse verwenden:
Workloads, die Daten mit kleineren I/O Größen lesen, erfordern eine höhere Parallelität und verursachen höhere Anforderungskosten, um den gleichen Durchsatz zu erzielen wie Workloads, die große I/O Größen verwenden, da die Latenz bei Speicherebenen höher ist. Intelligent-Tiering Wir empfehlen, Ihren SSD-Lesecache so zu konfigurieren, dass er die höhere Parallelität und den höheren Durchsatz bei der Arbeit mit kleineren I/O-Größen unterstützt.
Die maximale Festplatten-IOPS, die Ihre Clients mit einem Intelligent-Tiering Dateisystem erreichen können, hängt von den spezifischen Zugriffsmustern Ihrer Arbeitslast ab und davon, ob Sie einen SSD-Lesecache bereitgestellt haben. Bei Workloads mit Direktzugriff können Clients in der Regel viel höhere IOPS erzielen, wenn die Daten im SSD-Lesecache zwischengespeichert werden, als wenn sich die Daten nicht im Cache befinden.
Intelligent-Tiering Die Speicherklasse unterstützt Read-Ahead, um die Leistung für sequentielle Leseanforderungen zu optimieren. Wir empfehlen, Ihr Datenzugriffsmuster nach Möglichkeit sequentiell zu konfigurieren, um Daten vorab abrufen zu können und eine höhere Leistung zu erzielen.