Warum ist mein NVMe langsamer als SSD?

In diesem Artikel erörtern wir einige Aspekte der Eingabe-/Ausgabesysteme und ihre Auswirkungen auf die Leistung.

Vor ein paar Wochen stand ich vor der Frage, warum NVMe auf einem Server langsamer ist als SATA auf einem anderen. Ich schaute mir die Spezifikationen der Server an und stellte fest, dass es sich um eine trickreiche Frage handelte: NVMe stammte aus dem Consumer-Bereich, während die SSD aus dem Server-Bereich kam.

Offensichtlich ist es unangemessen, Produkte aus unterschiedlichen Segmenten in verschiedenen Umgebungen zu vergleichen, aber das ist nicht die 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 gehalten, bis sich eine geeignete Gelegenheit bietet, den Inhalt des Puffers auf das Speichergerät zu schreiben. Die Kriterien für den 'geeigneten Zeitpunkt' werden vom Betriebssystem und den Merkmalen des Speichermediums festgelegt. Bei einem Stromausfall gehen alle Daten im Puffer verloren.

Es gibt eine Reihe von Aufgaben, bei denen es wichtig ist, sicherzustellen, dass Änderungen an einer Datei auf das Speichermedium geschrieben sind und nicht im Zwischenspeicher bleiben. Dieses Vertrauen kann durch den POSIX-kompatiblen Systemaufruf fsync gewährleistet werden. Der Aufruf von fsync initiiert das erzwungene Schreiben aus dem Puffer auf das Speichermedium.

Lassen Sie uns den Einfluss von Puffern anhand eines einfachen Beispiels in einer kurzen C-Programm 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 einzelnen Schritte im Programm. Der Text „die Antwort auf die große Frage des Lebens, des Universums und allem“ wird von dem Betriebssystem gepuffert, und wenn der Server während der „Berechnungen“ durch Drücken der Reset-Taste neu gestartet wird, bleibt die Datei leer. In unserem Beispiel ist der Verlust des Textes kein Problem, daher ist fsync nicht notwendig. Datenbanken teilen jedoch diesen Optimismus nicht.

Datenbanken sind komplexe Programme, die gleichzeitig mit einer Vielzahl von Dateien arbeiten. Daher ist es für sie wichtig, sicherzustellen, dass die Daten, die sie speichern, auf dem Speicher gerettet werden, da dies die Konsistenz der Daten innerhalb der Datenbank beeinflusst. Datenbanken sind so konzipiert, dass sie alle abgeschlossenen Transaktionen aufzeichnen und jederzeit bereit sind, bei einem Stromausfall wiederhergestellt zu werden. Diese Anforderung zwingt dazu, fsync regelmäßig in großen Mengen zu verwenden.

Wie häufiges Verwenden von fsync Einfluss hat

Bei normalem I/O versucht das Betriebssystem, die Kommunikation mit den Festplatten zu optimieren, da externe Speicher in der Speichertierhierarchie die langsamsten sind. Aus diesem Grund versucht das Betriebssystem, bei jedem Zugriff auf den Speicher so viele Daten wie möglich auf einmal zu schreiben.

Lassen Sie uns die Auswirkungen der Verwendung von fsync anhand eines konkreten Beispiels demonstrieren. Bei unseren Testobjekten handelt es sich um die folgenden SSDs:

• 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. Für die Festplattentests wird sysbench 1.0.18 verwendet. Auf den Festplatten wurde eine Partition erstellt, die als ext4 formatiert ist. Die Vorbereitung auf den Test besteht darin, Dateien mit einem Volumen 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 aus dem Consumer-Segment klar führt, wenn das Betriebssystem selbst entscheidet, wie es mit den Festplatten umgeht, 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 ein SSD aus dem Server-Segment besser eine große Anzahl von fsync-Anfragen?

Die Antwort auf die erste Frage ist einfach: sysbench generiert Dateien, die mit Nullen gefüllt sind. Der Test wurde also mit 100 Gigabyte Nullen durchgeführt. Da die Daten sehr homogen und vorhersehbar sind, kommen verschiedene Optimierungen des Betriebssystems zum Einsatz, die die Ausführung erheblich beschleunigen.

Wenn man alle Ergebnisse von sysbench in Frage stellt, 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

Die Tendenz zur Leistungseinbuße bei NVMe bei Verwendung von fsync ist deutlich sichtbar. Wir können nun zur Beantwortung der zweiten Frage übergehen.

Optimierung oder Bluff

Früher haben wir erwähnt, dass die Daten im Speicher gehalten werden, aber nicht präzisiert, in welchem, da dies nicht entscheidend war. Auch jetzt wollen wir nicht in die Feinheiten der Betriebssysteme eintauchen und unterscheiden zwei allgemeine Typen von Puffern:

• softwarebasiert;
• hardwarebasiert.

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

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

• Die Festplatte ist für eine derartige Belastung ausgelegt;
• Die Festplatte "blufft" und ignoriert den Befehl.

Unredliches Verhalten des Speichermediums kann festgestellt werden, wenn man einen Test mit einem Stromausfall durchführt. Dies kann mit dem Skript diskchecker.pl, das erstellt wurde von Im Jahr 2005.

Dieses Skript benötigt 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 darüber, was geschrieben wurde.

# Запускается на сервере
./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 die Stromversorgung sollte für mehrere Minuten nicht wiederhergestellt werden. Es ist wichtig, den Testobjekt vollständig von der Stromversorgung zu trennen und nicht einfach einen harten Shutdown durchzuführen. Nachdem einige Zeit vergangen ist, kann der Server wieder angeschlossen und in das Betriebssystem geladen werden. Nach dem Booten des Betriebssystems muss man erneut starten diskchecker.pl, aber mit dem Argument verify.

./diskchecker.pl -s  verify

Am Ende der Prüfung sehen Sie die Anzahl der Fehler. Wenn es 0 Fehler sind, dann hat die Festplatte den Test bestanden. Um das zufällige positive Ergebnis für die Festplatte auszuschließen, kann der Test mehrmals wiederholt werden.

Unser S4500 hat bei einem Stromausfall keine Fehler gezeigt, daher kann man sagen, dass er für hohe Lasten mit vielen fsync-Aufrufen bereit ist.

Fazit

Bei der Auswahl von Festplatten oder gesamten Konfigurationen sollten die spezifischen Anforderungen, die erfüllt werden müssen, berücksichtigt werden. Auf den ersten Blick scheint es offensichtlich, dass NVMe, also SSDs mit PCIe-Schnittstelle, schneller sind als „klassische“ SATA-SSDs. Doch wie wir heute erfahren haben, kann dies unter bestimmten Bedingungen und für bestimmte Aufgaben nicht der Fall sein.

Wie testen Sie die Serverkomponenten bei der Anmietung von einem IaaS-Anbieter?
Wir freuen uns auf Ihre Kommentare.

Quelle: habr.com