Warum ist mein NVMe langsamer als SSD?

Warum ist mein NVMe langsamer als SSD?
In diesem Artikel betrachten wir einige Nuancen der Eingabe-/Ausgabesysteme und deren Einfluss auf die Leistung.

Vor ein paar Wochen stieß ich auf die Frage, warum NVMe auf einem Server langsamer ist als SATA auf einem anderen. Ich schaute mir die Spezifikationen der Server an und erkannte, dass dies eine Fangfrage war: NVMe stammte aus dem Consumer-Segment, während SSDs aus dem Server-Segment kamen.

Es ist offensichtlich, dass es nicht korrekt ist, Produkte aus unterschiedlichen Segmenten in unterschiedlichen Umgebungen zu vergleichen, aber das ist keine umfassende technische Antwort. Lassen Sie uns die Grundlagen untersuchen, Experimente durchführen und eine Antwort auf die gestellte Frage geben.

Was ist fsync und wo wird es verwendet?

Um die Arbeit mit Speichermedien zu beschleunigen, werden Daten gepuffert, das heißt, sie werden in flüchtigem Speicher gespeichert, bis sich ein günstiger Moment ergibt, um den Inhalt des Puffers auf das Speichermedium zu schreiben. Die Kriterien für diesen "günstigen Moment" werden vom Betriebssystem und den Eigenschaften des Speichermediums bestimmt. Bei einem Stromausfall gehen alle Daten im Puffer verloren.

Es gibt eine Reihe von Aufgaben, bei denen man sich sicher sein muss, dass Änderungen in einer Datei auf das Speichermedium geschrieben wurden und nicht im Zwischenspeicher liegen. Dieses Vertrauen kann man erhalten, wenn man den POSIX-kompatiblen Systemaufruf fsync verwendet. Der Aufruf von fsync initiiert das forciert Schreiben aus dem Puffer auf das Speichermedium.

Wir werden den Einfluss von Puffern anhand eines künstlichen Beispiels in Form eines kurzen Programms in C 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, "42n", 3); 

    return 0;
}

Die Kommentare erklären gut die Abfolge der Aktionen im Programm. Der Text "Antwort auf die entscheidende Frage des Lebens, des Universums und allem" wird vom Betriebssystem gepuffert, und wenn der Server während der "Berechnungen" durch Drücken des Reset-Buttons neu gestartet wird, bleibt die Datei leer. In unserem Beispiel ist der Verlust des Textes kein Problem, weswegen fsync nicht nötig ist. Datenbanken teilen diesen Optimismus nicht.

Datenbanken sind komplexe Programme, die gleichzeitig mit vielen Dateien arbeiten, weshalb sie sicherstellen möchten, dass die gespeicherten Daten auf dem Speichermedium erhalten bleiben, da dies die Konsistenz der Daten innerhalb der DB beeinflusst. Datenbanken sind so konzipiert, dass sie alle abgeschlossenen Transaktionen aufzeichnen und bereit sind, jederzeit vom Stromnetz getrennt zu werden. Dieses Verhalten zwingt dazu, fsync ständig in großen Mengen zu verwenden.

Wie beeinflusst häufige Nutzung von fsync

Bei normalem Ein- und Ausgabeversuch optimiert das Betriebssystem die Kommunikation mit den Festplatten, da externe Speicher in der Speicherehierarchie am langsamsten sind. Daher versucht das Betriebssystem, bei einem Zugriff auf das Speichermedium so viele Daten wie möglich auf einmal zu schreiben.

Wir demonstrieren den Einfluss der Verwendung von fsync an einem konkreten Beispiel. Unsere Testobjekte sind die folgenden Solid-State-Laufwerke:

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

Die Tests werden auf einem Intel® Xeon® W-2255 unter Ubuntu 20.04 durchgeführt. Zur Testverwendung der Laufwerke wird sysbench 1.0.18 eingesetzt. Auf den Laufwerken wurde eine Partition erstellt, die als ext4 formatiert ist. Die Vorbereitung für den Test besteht darin, Dateien mit einer Größe von 100 GB zu erstellen:

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

Start der 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.

Test
Intel® S4500
Samsung 970 EVO+

Lesen ohne fsync, MiB/s
5734.89
9028.86

Schreiben ohne fsync, MiB/s
3823.26
6019.24

Lesen mit fsync, MiB/s
37.76
3.27

Schreiben mit fsync, MiB/s
25.17
2.18

Es ist leicht zu erkennen, dass NVMe im Consumer-Segment klar führt, wenn das Betriebssystem selbst entscheidet, wie es mit den Laufwerken arbeitet, und verliert, wenn fsync verwendet wird. Daraus ergeben sich zwei Fragen:

  1. Warum überschreitet die Lesegeschwindigkeit im Test ohne fsync die physikalische Bandbreite des Kanals?
  2. Warum verarbeitet SSDs aus dem Server-Segment eine große Anzahl von fsync-Anfragen besser?

Die Antwort auf die erste Frage ist einfach: sysbench erzeugt Dateien, die mit Nullen gefüllt sind. Der Test wurde somit über 100 Gigabyte Nullen durchgeführt. Da die Daten sehr homogen und vorhersehbar sind, treten verschiedene Optimierungen des Betriebssystems in Kraft, die die Ausführung erheblich beschleunigen.

Wenn man alle Ergebnisse von sysbench in Zweifel zieht, kann man 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

Test
Intel® S4500
Samsung 970 EVO+

Lesen ohne fsync, MiB/s
45.5
178

Schreiben ohne fsync, MiB/s
30.4
119

Lesen mit fsync, MiB/s
32.6
20.9

Schreiben mit fsync, MiB/s
21.7
13.9

Der Trend zu einer Leistungsminderung bei NVMe beim Einsatz von fsync ist deutlich erkennbar. Wir können zur Beantwortung der zweiten Frage übergehen.

Optimierung oder Bluff

Früher haben wir gesagt, dass die Daten im Puffer gespeichert werden, aber wir haben nicht spezifiziert, in welchem, da es nicht entscheidend war. Auch jetzt werden wir nicht auf die Feinheiten von Betriebssystemen eingehen und zwei allgemeine Arten von Puffern hervorheben:

  • softwarebasiert;
  • hardwarebasiert.

Unter einem softwarebasierten Puffer versteht man Puffer, die im Betriebssystem vorhanden sind, während hardwarebasiert ein flüchtiger Speicher des Festplattencontrollers ist. Der Systemaufruf fsync sendet dem Speichergerät den Befehl, die Daten aus seinem Puffer in den Hauptspeicher zu schreiben, kann jedoch die Korrektheit der Ausführung des Befehls nicht überwachen.

Da SSDs bessere Ergebnisse zeigen, können zwei Annahmen getroffen werden:

  • Die Festplatte wurde für eine solche Belastung ausgelegt;
  • Die Festplatte blufft und ignoriert den Befehl.

Unredliches Verhalten des Speichermediums kann festgestellt werden, wenn ein Test mit Stromausfall durchgeführt wird. Dies kann mit dem Skript diskchecker.plüberprüft werden, das erstellt wurde im Jahr 2005.

Dieses Skript erfordert zwei physische Maschinen – einen 'Server' und einen 'Client'. Der Client schreibt eine kleine Datenmenge auf die zu testende Festplatte, ruft fsync auf und sendet dem Server Informationen über das Geschriebene.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

Nach dem Start des Skripts muss der 'Client' vom Stromnetz getrennt werden, und es darf mehrere Minuten lang kein Strom zurückgegeben werden. Es ist wichtig, das Gerät tatsächlich vom Strom zu trennen und nicht einfach einen harten Shutdown durchzuführen. Nach einer gewissen Zeit kann der Server angeschlossen und das Betriebssystem geladen werden. Nach dem Booten des Betriebssystems muss das Skript erneut gestartet werden diskchecker.pl, aber mit dem Argument verify.

.\/diskchecker.pl -s  verify

Am Ende der Überprüfung sehen Sie die Anzahl der Fehler. Wenn sie 0 beträgt, hat die Festplatte den Test bestanden. Um das für die Festplatte günstige Ergebnis auszuschließen, kann der Test mehrere Male wiederholt werden.

Unsere S4500 hat bei einem Stromausfall keine Fehler gezeigt, das bedeutet, dass man behaupten kann, dass sie für Lasten mit einer großen Anzahl von fsync-Aufrufen bereit ist.

Fazit

Bei der Auswahl von Festplatten oder kompletten Konfigurationen sollte man sich der spezifischen Aufgaben bewusst sein, die gelöst werden müssen. Auf den ersten Blick scheint es offensichtlich, dass NVMe, also SSDs mit PCIe-Schnittstelle, schneller sind als „klassische“ SATA SSDs. Wie wir jedoch heute festgestellt haben, kann es unter bestimmten Bedingungen und mit spezifischen Aufgaben nicht so sein.

Wie testen Sie die Komponenten von Servern, wenn Sie bei einem IaaS-Anbieter mieten?
Wir freuen uns auf Ihre Kommentare.

Warum ist mein NVMe langsamer als SSD?

Quelle: habr.com

60GB SSD 8Gb DDR4