Freigeben über


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