Eine von ZimaOS Files gemeldete Kopiergeschwindigkeit von etwa 600–650 MB/s beweist nicht, dass das NVMe-Gerät selbst auf SATA-Geschwindigkeit begrenzt ist. Die Community-Anleitung der Quelle trennt korrekt zwischen Raw-Speicherdurchsatz und Durchsatz des Dateikopier-Workflows. Ein browserbasierter Dateimanager kann Metadatenverarbeitung, Fortschrittsverfolgung, Sicherheitslogik, Kopiervorgänge im Userspace, Dateisystem-Overhead und dateiweise Operationen hinzufügen, die ein direkter Benchmark nicht misst.
Am sinnvollsten ist ein Vergleich: Testen Sie denselben Speicher mit einer großen sequenziellen Direkt-E/A-Auslastung und kopieren Sie anschließend dieselbe große Datei über die CLI und über Files. Wenn die Raw-/Direkttests mehrere GB/s erreichen, während der GUI-Kopiervorgang bei etwa 600 MB/s bleibt, liegt der Engpass wahrscheinlich oberhalb des NVMe-Geräts.
Eine einzelne Dateikopierzahl ist kein NVMe-Benchmark
Die interne Kopiergeschwindigkeit hängt ab von:
- Quelle und Ziel auf demselben oder auf unterschiedlichen Geräten;
- Dateisystemtyp;
- Copy-on-Write-Verhalten;
- Dateigröße und Dateianzahl;
- CPU-Overhead;
- Page-Cache;
- die Kopierimplementierung.
Ein Ergebnis von 600 MB/s kann für einen Arbeitsablauf hervorragend und für einen anderen schlecht sein.
Mit einer großen sequenziellen Testdatei beginnen
Große Dateien reduzieren den Metadaten-Overhead und erleichtern die Interpretation des dauerhaften Durchsatzes. Die Quelle verwendete eine 10-GB-Datei, damit die Auslastung lange genug lief, um sie beobachten zu können.
Bevor Sie eine große Testdatei erstellen, prüfen Sie, ob auf dem Zielspeicher ausreichend freier Speicherplatz vorhanden ist. Ein Benchmark, der die System- oder Datendisk füllt, kann einen anderen Fehler verursachen.
Die Quelle verwendete dd mit direkten Schreibvorgängen
Die Anleitung aus der Community schlug vor:
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct reduziert die Auswirkungen des Page-Caches beim Schreiben. Dies ist für eine grobe Prüfung sequenzieller Schreibvorgänge nützlich.
Gehen Sie nicht davon aus, dass jeder Build, jedes Gerät und jedes Dateisystem dieselbe Blockgröße oder dasselbe Verhalten bei direkter E/A identisch akzeptiert.
Den dd-Lesetest der Quelle vorsichtiger interpretieren
Die Quelle las die Datei anschließend, um /dev/null. Ohne eine Option für direkte Lese-E/A oder eine Cache-Steuerung kann eine kürzlich erstellte Datei teilweise aus dem Page-Cache bereitgestellt werden und die scheinbare Lesegeschwindigkeit überhöhen.
Für einen zuverlässigen Speichervergleich sollten Sie ein Tool/eine Konfiguration bevorzugen, das bzw. die direkte E/A in beide Richtungen explizit verwendet, oder sicherstellen, dass Sie die Auswirkungen des Cachings verstehen.
fio ist der besser kontrollierbare Speichertest
Das Beispiel für dauerhaftes Schreiben aus der Quelle verwendete:
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingDies ist nach wie vor eine Anleitung aus der Community, hat aber eine klarere Benchmark-Struktur: explizite Testgröße, sequenzielle Schreibvorgänge, Warteschlangentiefe, direkte E/A, Laufzeit und gruppierte Ergebnisse.
Richten Sie niemals einen destruktiven fio-Job auf ein Raw-Gerät mit echten Daten. Verwenden Sie stattdessen eine temporäre Testdatei auf einem Dateisystem, sofern Sie die Folgen nicht vollständig verstehen.
GUI und CLI mit demselben Datensatz vergleichen
Der wichtigste methodische Rat der Quelle lautet, dieselbe große Datei für beide zu verwenden:
- Eine CLI-Kopie;
- Eine Kopie über „Dateien“ von ZimaOS.
Wenn Datensatz, Quelle, Ziel und Dateisystem identisch sind, spiegelt der Unterschied die Kopierpipeline direkter wider.
Kleine Dateien können dramatisch langsamer sein
Tausende Fotos, Projektdateien, Vorschaubilder oder AppData-Einträge erfordern wiederholte Öffnen-/Erstellen-/Metadaten-/Prüfsummenoperationen. Die aggregierte Übertragungsrate kann selbst auf sehr schnellen NVMe-Laufwerken weit unter der Rate einer einzelnen großen Film- oder ISO-Datei liegen.
Copy-on-Write und Metadatenverhalten von Btrfs können je nach genauer Operation zusätzlichen Overhead verursachen.
CPU und I/O während des langsamen Kopiervorgangs überwachen
Die Quelle empfiehlt, die Datenträgerauslastung und die CPU gleichzeitig zu beobachten. Ziel ist festzustellen, ob:
- Der Datenträger ist ausgelastet;
- Ein CPU-Kern bildet den Engpass;
- Ein anderer Prozess konkurriert um die I/O-Ressourcen;
- Die Kopierpipeline wartet, statt den Speicher auszulasten.
Das ist aussagekräftiger, als nur die Zahl in der Fortschrittsanzeige von „Dateien“ zu nennen.
Die NVMe-Geschwindigkeit hängt auch von den PCIe-Lanes und dem Gerät ab
Selbst eine einwandfreie NVMe kann unter ihrer beworbenen Geschwindigkeit liegen, wenn:
- Der Steckplatz verwendet PCIe x1/x2 statt x4;
- Die Plattform verwendet PCIe Gen 3 statt Gen 4;
- Die SSD wird thermisch gedrosselt;
- Der Controller teilt sich die Lanes;
- Der SLC-Cache ist während anhaltender Schreibvorgänge erschöpft.
Ein echter Benchmark sollte mit der Hardwaretopologie und nicht mit der allgemeinen Erwartung „NVMe = 7 GB/s“ verglichen werden.
Aktuelle Übertragungsleitfäden von IceWhale trennen ebenfalls UI- und schnellere Übertragungswege
Der Thunderbolt-Leitfaden von IceWhale für ZimaCube zeigte in der Vergangenheit, dass der Übertragungsweg über die ZimaOS-Benutzeroberfläche langsamer läuft als ein direkter Samba-/Thunderbolt-Weg. Das unterstreicht den allgemeinen Punkt, dass die Dateibenutzeroberfläche nicht mit dem rohen Durchsatz von Netzwerk oder Speicher identisch ist.
Verwenden Sie die aktuelle Checkliste zur Behebung von Übertragungsproblemen in ZimaOS für unterstützte netzwerkseitige Prüfungen.
Testdateien nach Abschluss löschen
Groß dd/fio Dateien können schnell Dutzende Gigabyte Speicherplatz belegen. Entfernen Sie die bekannten Testdateien, nachdem Sie die Ergebnisse aufgezeichnet haben, und überprüfen Sie anschließend den freien Speicherplatz.
FAQ zum NVMe-Benchmark
Beweist eine Geschwindigkeit von 600 MB/s in „Dateien“ von ZimaOS, dass die NVMe auf SATA-Geschwindigkeit begrenzt ist?
Nein. Es misst diesen Kopierworkflow, nicht die rohe NVMe-Leistung.
Warum kann ein dd-Lesevorgang unrealistisch schnell erscheinen?
Eine kürzlich geschriebene Datei kann teilweise aus dem Seiten-Cache bereitgestellt werden, sofern der Lesetest das Caching nicht ausdrücklich vermeidet.
Was ist der beste Vergleich für die GUI-Kopierpipeline?
Verwenden Sie dieselbe Quelle und dasselbe Ziel sowie denselben großen Datensatz sowohl in der CLI als auch in „Dateien“ und vergleichen Sie die Ergebnisse, während Sie CPU- und Speicher-I/O überwachen.
