Bewährte Methoden in Bezug auf direkte E/A unter Linux für Azure NetApp Files
Dieser Artikel hilft Ihnen dabei, die Best Practices für die direkte E/A für Azure NetApp Files besser zu verstehen.
Direkte E/A
Der gängigste Parameter beim Benchmarking der Speicherleistung ist die direkte E/A. Sie wird von FIO und Vdbench unterstützt. DISKSPD bietet Unterstützung für das ähnliche Konstrukt der E/A mit Arbeitsspeicherzuordnung. Bei der direkten E/A wird der Cache des Dateisystems umgangen, Vorgänge für einen direkten Speicherzugriff werden vermieden, und Speichertests sind schnell und einfach.
Mit dem Parameter für direkte E/A ist das Testen des Speichers ganz einfach. Es werden keine Daten aus dem Dateisystemcache auf dem Client gelesen. Daher ist der Test ein echter Belastungstest für das Speicherprotokoll und den Dienst selbst, nicht für die Geschwindigkeit des Arbeitsspeicherzugriffs. Ohne die DMA-Arbeitsspeicherkopien sind Lese- und Schreibvorgänge aus Verarbeitungsperspektive effizient.
Nehmen Sie als Beispielworkload den Linux-Befehl dd
. Ohne das optionale odirect
-Flag werden sämtliche von dd
generierten E/A-Vorgänge aus dem Linux-Puffercache bedient. Lesevorgänge, deren Blöcke sich bereits im Arbeitsspeicher befinden, werden nicht aus dem Speicher abgerufen. Lesevorgänge, die zu einem Puffercachefehler führen, werden per NFS-Read-Ahead-Vorgang aus dem Massenspeicher gelesen. Dabei kommt es, abhängig von Faktoren wie dem rsize
-Bereitstellungswert und Client-Read-Ahead-Einstellungen, zu unterschiedlichen Ergebnissen. Wenn Schreibvorgänge über den Puffercache gesendet werden, verwenden sie einen Write-Behind-Mechanismus, der nicht optimiert ist und ein erhebliches Maß an Parallelität benötigt, um die Daten an das Speichergerät zu senden. Möglicherweise kommen Sie in Versuchung, zwei unabhängige E/A-Datenströme auszuführen, einen dd
-Datenstrom für Lesevorgänge und einen dd
-Datenstrom für Schreibvorgänge. Tatsächlich zieht das Betriebssystem ohne Optimierung die Schreibvorgänge den Lesevorgängen vor und verwendet mehr Parallelität.
Abgesehen von Datenbanken verwenden sehr wenige Anwendungen direkte E/A-Vorgänge. Stattdessen nutzen sie die Vorteile eines großen Arbeitsspeichercaches für wiederholte Lesevorgänge und einen Write-Behind-Cache für asynchrone Schreibvorgänge. Kurz gesagt: Die Verwendung der direkten E/A verwandelt den Test in einen Mikrobenchmark, wenn die Anwendung, die synthetisiert werden soll, den Dateisystemcache verwendet.
Im Folgenden finden Sie einige Datenbanken, die direkte E/A unterstützen:
- Oracle
- SAP HANA
- MySQL (InnoDB-Speicher-Engine)
- RocksDB
- PostgreSQL
- Teradata
Bewährte Methoden
Das Testen mit directio
ist eine hervorragende Möglichkeit, die Grenzwerte von Speicherdienst und Client zu verstehen. Um besser zu verstehen, wie sich die Anwendung verhält (wenn sie nicht directio
verwendet), sollten Sie auch Tests über den Dateisystemcache ausführen.
Nächste Schritte
- Bewährte Methoden in Bezug auf den Linux-Dateisystemcache für Azure NetApp Files
- Einbindungsoptionen für NFS unter Linux: bewährte Methoden für Azure NetApp Files
- Bewährte Methoden für Linux-Parallelität für Azure NetApp Files
- Bewährte Methoden für NFS-Read-Ahead unter Linux
- Bewährte Methoden für SKUs für virtuelle Azure-Computer
- Leistungsbenchmarks für Linux