SSD Lesen / Schreiben manuell testen

340
John Frye

Ich versuche, die Lese- und Schreibgeschwindigkeit einer SSD über NVMe manuell zu testen. Die aktuelle Methode, die ich verwende, ist das Einhängen eines Dateisystems auf der SSD und das Lesen / Schreiben von 20 GB in eine Datei in diesem Dateisystem in Blockgrößen von 4 KB, 32 KB, 128 KB, 215 KB, 1 MB, 64 MB, 256 MB und 1 GB während der Aufnahme der Zeitpunkt des Beginns des Lese- / Schreibvorgangs und der Zeitpunkt des Abschlusses. Dieser Prozess wird von einem Bash-Skript aus aufgerufen. Das Bash-Skript versucht, mehrere "Anwendungen" auszuführen, indem es die untere Funktion n-mal aufruft, jedes Mal, wenn der Prozess im Hintergrund ausgeführt wird.

while [ $instCnt -le $appInstances ] do fsrw -w $blocksize /fsmnt/fs$/usernumber1/j.j &

Hier ist die Lesefunktion aus der ausführbaren Datei fsrw

bool perform_readop () { // File descriptor. int32_t fd = -1;  // Function status. bool status = false;  //Zero read count int zero_reads = 0;  // Open the file. fd = open (fname.c_str (), O_RDONLY);  // Verify the file has been opened. if (fd == -1) { cout << get_datetime_string() << "Read open of " << fname << " failed. Errno: "  << errno << endl; } else { // Total bytes read. uint64_t rd = 0;  // Elapsed time. struct timeval tv = { 0 }; get_elapsed_time (&tv);  // Notify the user that the read test has started. cout << get_datetime_string() << "Starting read" << endl;  while(rd < READ_LIMIT && zero_reads < 10) { // Run until it is time for the test to stop. ssize_t readsize = read (fd, &buf[0], blocksize); if (readsize == -1) { cout << get_datetime_string << "Read failure. Errno: " << errno << endl; zero_reads = 10; } else if (readsize == 0) { cout << get_datetime_string << "Reached EOF." << endl; zero_reads++; } else { rd += readsize; } }  // Get the elapsed time. get_elapsed_time (&tv);  // Report the number of bytes read. cout << get_datetime_string() << "Read " << rd << " bytes in " << tv.tv_sec << "."  << tv.tv_usec << " seconds, bytes per second " << bytes_per_second (&tv, rd) << endl;  // Close the file. close (fd);  // Set the function return status when all read operations have // been successful. if (zero_reads < 10) { status = true; } }  return status;  }

Ich habe diese Methode aus der Arbeit anderer Leute portiert und bin mir wirklich nicht sicher, ob dies eine gültige Methode ist, um die Durchsatzrate der SSD zu überprüfen. Die Ergebnisse des Tests, insbesondere für den Lesevorgang, sind nicht realistisch. Sie sind viel höher als erwartet. Fio schlägt vor, dass der Durchsatz bei Lesen und Schreiben um 500 MB / s liegen sollte, aber dies testet Schreibgeschwindigkeiten von 1 GB + / s und Lesegeschwindigkeiten nahe 8 GB / s

0
Ich vermute, dass es wahrscheinlich damit zusammenhängt, dass das Betriebssystem die Dateien zwischenspeichert und die SSD selbst die Daten zwischenspeichert. Das genaue Messen des SSD-Durchsatzes ist keine leichte Aufgabe. James P vor 6 Jahren 0
Ich hatte das Gefühl, dass der nvme Controller zwischengespeichert hat. Ich wollte nur etwas Input bekommen. Es sieht so aus, als wenn ich 4 Anwendungen ausführen und einen Schreibvorgang ausführen würde, wenn ich wieder zum Lesen gehe, wird der erste Lesevorgang der 4 Anwendungen superschnell abgeschlossen. Caching könnte das erklären. Ich weiß nicht, wie ich das umgehen kann, außer indem ich meinen eigenen Fahrer schreibe. Das wäre nicht trivial John Frye vor 6 Jahren 0
Wenn Sie die Testdateien auf die SSD schreiben und einen Neustart durchführen (mit Stromausfall, um auf der paranoiden Seite zu sein), werden sich Ihre Dateien beim ersten Lesen nach dem Neustart nicht in Puffern befinden. Unmount / remount sollte sich ebenfalls darum kümmern beliebige Zwischenspeicherung auf Betriebssystemebene xenoid vor 6 Jahren 0
Ich habe es in meinem Bash-Skript zwischen Lesen und Schreiben aufgehoben und neu bereitgestellt. Es gab einen Fehler, der besagte, dass es immer noch Prozesse gibt, die die Partitionen der SSD betreffen. Ich frage mich, ob es in bash eine Möglichkeit gibt, diese Operation auszuführen, bis sie erfolgreich ist. John Frye vor 6 Jahren 0

1 Antwort auf die Frage

0
Anon

Es ist unklar, was Ihre Frage ist - Sie scheinen zu fragen, "warum sind meine Ergebnisse nicht realistisch (und warum sind sie schneller als die von fio?"). Sie nehmen Ihren fio-Job nicht auf, so dass es unmöglich ist, dazu etwas zu sagen :-( Ich weiß auch nicht, was das Programm fsrw macht. Ich werde mich bemühen, was bleibt:

Nehmen wir an, wir haben nur Ihr Programm und den Kernel (dies ist eine Vereinfachung). Ihr Programm gibt Schreibvorgänge aus, und der Kernel sagt "yup, ich habe sie", sobald er sie in einem internen Puffer in eine Warteschlange stellt, wodurch Ihr Programm seinen Weg gehen kann. Nur wenn der interne Kernelpuffer zu voll ist, blockiert Ihr Programm so lange, bis genügend Speicherplatz vorhanden ist. Das heißt, wenn ein Programm "kleine" Datenmengen auf ein leises System schreibt, wird es niemals auf die Disk warten, um die I / Os zu bedienen - wir haben sie durch die Verwendung eines Puffers von der Geschwindigkeit der Diskette abgekoppelt. Natürlich kann diese Illusion nur so lange dauern und hängt davon ab, wie groß der Puffer ist, wie voll er ist usw.

Wenn der RAM nicht verwendet wird, kann der Kernel außerdem Teile der Datenträger zwischenspeichern. Wenn ich Daten auf die Festplatte schreibe, werden die Daten, die ich schreibe, später nicht nur zwischengespeichert und geleert, sondern auch, wenn noch Speicherplatz vorhanden ist. Sie können auch nach dem Spülen herumgehalten werden, falls sie später benötigt werden. Sie können diesen Effekt sehen, wenn Sie eine Datei schreiben und dann die Datei nach freiem Zugriff prüfen. In der Regel werden Sie feststellen, dass der RAM-Speicherplatz gesunken ist, weil Teile dieser Datei im Cache gehalten werden. Wenn ich es aus dem Cache von Linux auslese, ist die Geschwindigkeit, die ich erreiche, in der Nähe der RAM-Geschwindigkeit und die Festplatte bleibt unangetastet (wenn Sie wissen, wie Iostat verwendet wird, werden Sie feststellen, dass keine / viele Festplatten gemeldet werden. O wenn dies geschieht).

So:

  • Normale Schreib-E / A können gepuffert werden
  • Normale E / A können zwischengespeichert werden
  • Das Lesen zwischengespeicherter Daten ist VIEL schneller als das Lesen nicht zwischengespeicherter Daten
  • Ihr Leseprogramm ist anfällig für den vorherigen Punkt

Beachten Sie, dass dies eine Vereinfachung ist. Ich habe nicht über Dinge wie Readahead oder Dateisysteminteraktionen berichtet, warum Sie fsyncund so weiter.

Zusätzlich können Blöcke, die vom Kernel nach unten in Richtung der Platte gesendet werden, von der Größe abweichen, die Ihr Programm sie übermittelt. Sie können 16 x 4 KByte zusammenhängende Schreibvorgänge an den Kernel senden, aber der Kernel kann diese zusammenführen und ein einzelnes 64 KByte-Schreiben auf die Festplatte senden. Dies ist in der Regel von Vorteil, aber im synthetischen Benchmarking muss man sich dessen bewusst sein.

Zusammenfassend würde ich vermuten, dass Ihre Ergebnisse "unrealistisch" sind, weil Sie massiv von der Pufferung und dem Zwischenspeichern von Linux profitieren. Wenn Ihre tatsächliche Arbeitslast wirklich so ist, dann ist die Geschwindigkeit Ihrer SSD kein Engpass und schnellere Festplatten helfen Ihnen nicht viel (so realistisch ist ein kniffliges Wort)! Sie können Zahlen erhalten, die näher an der SSD liegen, indem Sie sicherstellen, dass Ihre Datensatzgröße um ein Vielfaches (mindestens dreimal) größer ist als der Gesamtspeicher Ihres Systems, oder indem Sie E / A-Vorgänge ausführen, die nicht gepuffert oder zwischengespeichert werden können . Ich kann nicht sagen, warum Sie langsamer sind als fio-Läufe, weil jede Antwort darauf sehr fio-spezifisch ist und kein Job in der Frage enthalten ist.

Verwandte Probleme