Warum ist mein NVMe langsamer als meine SSD?

In diesem Artikel werden einige der Nuancen des E / A-Subsystems und ihre Auswirkungen auf die Leistung untersucht.



Vor ein paar Wochen bin ich auf die Frage gestoßen, warum NVMe auf einem Server langsamer ist als SATA auf einem anderen. Ich habe mir die Eigenschaften der Server angesehen und festgestellt, dass dies eine Trickfrage war: NVMe stammte aus dem Benutzersegment und die SSD aus dem Serversegment.



Der Vergleich von Produkten aus verschiedenen Segmenten in verschiedenen Umgebungen ist natürlich falsch, aber dies ist keine erschöpfende technische Antwort. Lassen Sie uns die Grundlagen lernen, experimentieren und die Frage beantworten.

Was ist fsync und wo wird es verwendet?

Um die Arbeit mit Laufwerken zu beschleunigen, werden Daten gepuffert, dh in einem flüchtigen Speicher gespeichert, bis sich eine günstige Gelegenheit bietet, den Inhalt des Puffers auf dem Laufwerk zu speichern. Die "Opportunity" -Kriterien werden vom Betriebssystem und den Eigenschaften des Laufwerks bestimmt. Bei einem Stromausfall gehen alle Daten im Puffer verloren.



Es gibt eine Reihe von Aufgaben, bei denen Sie sicherstellen müssen, dass Änderungen in einer Datei auf das Laufwerk und nicht in einen Zwischenpuffer geschrieben werden. Dieses Vertrauen kann durch die Verwendung des POSIX-kompatiblen fsync-Systemaufrufs gewonnen werden. Der fsync-Aufruf initiiert ein erzwungenes Schreiben vom Puffer auf das Laufwerk.



Lassen Sie uns die Wirkung von Puffern anhand eines künstlichen Beispiels in Form eines kurzen C-Programms demonstrieren.

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /*   answer.txt  ,    --  */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /*     */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /*  ,      10  */
    sleep(10);
    /*    */
    write(fd, "42\n", 3); 

    return 0;
}

Die Kommentare erklären gut die Abfolge der Aktionen im Programm. Der Text "Die Antwort auf die Hauptfrage des Lebens, des Universums und all das" wird vom Betriebssystem gepuffert. Wenn Sie den Server durch Drücken der Schaltfläche "Zurücksetzen" während "Berechnungen" neu starten, ist die Datei leer. In unserem Beispiel ist der Textverlust kein Problem, daher wird fsync nicht benötigt. Datenbanken teilen diesen Optimismus nicht.



Datenbanken sind komplexe Programme, die gleichzeitig mit vielen Dateien arbeiten. Sie möchten daher sicherstellen, dass die von ihnen geschriebenen Daten auf dem Laufwerk gespeichert werden, da die Konsistenz der Daten in der Datenbank davon abhängt. Die Datenbanken sind so konzipiert, dass sie alle abgeschlossenen Transaktionen aufzeichnen und jederzeit für Stromausfälle bereit sind. Dieses Verhalten verpflichtet uns, fsync ständig in großen Mengen zu verwenden.

Welche Auswirkungen die häufige Verwendung von fsync hat

Bei normaler E / A versucht das Betriebssystem, die Kommunikation mit Festplatten zu optimieren, da externe Laufwerke die langsamsten in der Speicherhierarchie sind. Daher versucht das Betriebssystem, so viele Daten wie möglich in einem Aufruf an das Laufwerk zu schreiben.



Lassen Sie uns anhand eines bestimmten Beispiels die Auswirkungen der Verwendung von fsync demonstrieren. Wir haben die folgenden SSDs als Testpersonen:

• Intel® DC SSD S4500 480 GB, verbunden über SATA 3.2, 6 Gbit / s;
• Samsung 970 EVO Plus 500 GB, PCIe 3.0 x4, ~ 31 Gbit / s.

Die Tests werden mit Intel® Xeon® W-2255 unter Ubuntu 20.04 durchgeführt. Mit Sysbench 1.0.18 werden Festplatten getestet. Auf den Laufwerken wird eine Partition erstellt, die als ext4 formatiert ist. Die Vorbereitung für den Test besteht aus der Erstellung von 100-GB-Dateien:

sysbench --test=fileio --file-total-size=100G prepare

Ausführen von Tests:

#  fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

#  fsync   
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

Die Testergebnisse sind in der Tabelle dargestellt.

Es ist leicht zu erkennen, dass NVMe aus dem Client-Segment sicher führend ist, wenn das Betriebssystem selbst entscheidet, wie mit Festplatten gearbeitet wird, und verliert, wenn fsync verwendet wird. Dies wirft zwei Fragen auf:

1. Warum überschreitet im Test ohne fsync die Lesegeschwindigkeit die physische Bandbreite?
2. Warum kann eine serverseitige SSD eine große Anzahl von fsync-Anforderungen besser verarbeiten?

Die Antwort auf die erste Frage ist einfach: sysbench generiert mit Nullen gefüllte Dateien. Somit wurde der Test über 100 Gigabyte Nullen durchgeführt. Da die Daten sehr eintönig und vorhersehbar sind, kommen verschiedene Betriebssystemoptimierungen ins Spiel, die die Ausführung erheblich beschleunigen.



Wenn Sie alle Sysbench-Ergebnisse in Frage stellen, können Sie fio verwenden.

#  fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

#  fsync   
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

Die Tendenz, dass die NVMe-Leistung bei Verwendung von fsync abnimmt, ist deutlich sichtbar. Sie können mit der Antwort auf die zweite Frage fortfahren.

Optimierung oder Bluff

Früher haben wir gesagt, dass die Daten in einem Puffer gespeichert sind, aber wir haben nicht angegeben, welcher, da dies nicht wichtig war. Wir werden jetzt nicht weiter auf die Feinheiten von Betriebssystemen eingehen und zwei allgemeine Arten von Puffern hervorheben:

• Programm;
• Hardware.

Der Softwarepuffer bezieht sich auf die Puffer im Betriebssystem, und der Hardwarepuffer bezieht sich auf den flüchtigen Speicher des Plattencontrollers. Der Systemaufruf fsync sendet einen Befehl an das Laufwerk, um Daten aus seinem Puffer in den Hauptspeicher zu schreiben, kann jedoch die Richtigkeit der Befehlsausführung nicht kontrollieren.



Da SSDs eine bessere Leistung erbringen, können zwei Annahmen getroffen werden:

• Die Festplatte ist für eine solche Last ausgelegt.
• Die Festplatte blufft und ignoriert den Befehl.

Sie können das unehrliche Verhalten des Laufwerks feststellen, wenn Sie einen Stromausfalltest durchführen. Sie können dies mit dem Skript diskchecker.pl überprüfen , das 2005 erstellt wurde.



Dieses Skript erfordert zwei physische Maschinen - "Server" und "Client". Der Client schreibt eine kleine Datenmenge auf die zu testende Festplatte, ruft fsync auf und sendet dem Server Informationen darüber, was geschrieben wurde.

#   
./diskchecker.pl -l [port]

#   
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Nach dem Ausführen des Skripts muss der "Client" deaktiviert und einige Minuten lang nicht mit Strom versorgt werden. Es ist wichtig, die zu testende Person vom Stromnetz zu trennen und nicht nur eine harte Abschaltung durchzuführen. Nach einiger Zeit kann der Server verbunden und in das Betriebssystem geladen werden. Nach dem Start des Betriebssystems müssen Sie diskchecker.pl erneut ausführen , jedoch mit dem Argument verify .

./diskchecker.pl -s <server[:port]> verify <file>

Am Ende der Prüfung sehen Sie die Anzahl der Fehler. Wenn 0 vorhanden sind, hat die Festplatte den Test bestanden. Um eine Kombination von Umständen auszuschließen, die für die Disc erfolgreich sind, kann das Experiment mehrmals wiederholt werden.



Unser S4500 zeigte keine Stromausfallfehler, daher kann argumentiert werden, dass er für Lasten mit vielen fsync-Aufrufen bereit ist.

Fazit

Wenn Sie Festplatten auswählen oder vorgefertigte Konfigurationen abschließen, sollten Sie sich an die Besonderheiten der Aufgaben erinnern, die gelöst werden müssen. Auf den ersten Blick scheint es offensichtlich, dass NVMe, dh SSD mit PCIe-Schnittstelle, schneller ist als die "klassische" SATA-SSD. Wie wir heute verstanden haben, ist dies unter bestimmten Bedingungen und bei bestimmten Aufgaben möglicherweise nicht der Fall.



Wie testen Sie Serverkomponenten, wenn Sie bei einem IaaS-Anbieter mieten?

Wir warten in den Kommentaren auf Sie.