Test Intel Optane SSD DC P4800X: Das leistet 3D XPoint im Server-Format

[Holt]

Eben, die HW muss bei der maximal zu erwartenden Last noch ausreichend schnell laufen, sonst hat man Schönwettersysteme gebaut und wird beim ersten Regen nass

Wer sich Gedanken machen muss wo er mit so einer Optane Vorteile hätte, wird wohl kaum etwas finden wo dies der Fall ist und damit kaum zur Zielgruppe gehören. Der Rest weiß schon wo der Schuh drückt und wird schauen wie viel Gewinn er von der Optane ziehen kann und da können 10% schon genug sein um die Anschaffung rentabel zu machen, denn wenn man fast 10% der Server einsparen kann weil jeder mit der Optane 10% mehr leistet, dann kommen da schnell Einsparungen zusammen die weit über den Kosten für so eine Optane liegen.

Bei Heimanwendern wird dies kaum der Fall sein und die werden sich dann die 900P statt der 4800X kaufen, wenn sie sie sich leisten können und wollen und weil sie sie haben wollen.

 

[HaZweiOh]

Der Grundsatz steht recht vielen aktuellen Entwicklungen entgegen.

Ich meinte Anwendungsgebiete.

 

[Hallo32]

Im Prinzip zeigt der Test sehr gut, dass sich eine Optane im privaten Einsatz kaum von einer aktuellen NVMe SSD abheben kann.

 

[INe5xIlium]

Ich persönlich hatte schon einige Male das Problem, dass ich Ordner mit Quellcodedateien kopiert habe, was trotz einer Samsung 850Pro nur Übertragungsraten im einstelligen MB Bereich gebracht hat und locker mal 20 Minuten gedauert hat.

So extrem ist es sehr selten, da hätte ich mir aber etwas gewünscht, was schneller funktioniert (Kopieren mit Robocopy ging erstaunlich viel schneller als mit dem Explorer).

Andererseits ist es auch nicht so häufig, dass ich Gigabyte an winzigen Dateien verschiebe. Ich frage mich dennoch, ob die Optane da signifikant schneller ist.

 

[Hallo32]

In den Fall dürfte es auch an der Implementierung im Windows Explorer liegen, wie du selbst schreibst, hing es mit Robocopy viel schneller.

Ein identisches Verhalten zeigt sich, wenn 100k Dateien einen Git Repo hinzugefügt werden.

Solches Test wären wirklich spannend, dürften aber die meisten Leser hier nicht wirklich interessieren.

 

[xexex]

Solches Test wären wirklich spannend, dürften aber die meisten Leser hier nicht wirklich interessieren.

Im Test wird mehr oder weniger explizit darauf eingegangen.

In order to get the most of your storage subsystem, you need to queue up enough IO requests to keep the entire system busy end-to-end. For instance, when using hard disk drives, we like to watch the queue depth performance counters to make sure we maintain at least two IOs queued for each HDD you have in a system.

In order to take advantage of this, when you’re copying large files using the Windows copy engine, it will issue 8 asynchronous writes of 1MB each by default. However, when copying lots of small files (and using a fast storage backend), you are less likely to stand up the required IO queue depth unless you queue more IOs and use multiple threads.

To make matters worse, most file copy programs will copy only one file at a time, waiting for one file copy to finish before starting the next one. This serialization will give you a much lower storage performance than the system is actually capable of delivering when more requests are being queued in parallel.
...
Most file copy tools like the EXPLORER.EXE GUI, the COPY command in the shell, the XCOPY.EXE tool and the PowerShell Copy-Item cmdlet not optimized for performance. They are single-threaded, one-file-at-a-time solutions that will do the job but are not designed to transfer files as fast as possible.

The best file copy tool included in Windows is actually the ROCOBOPY.EXE tool. It includes very useful options like /MT (for using multiple threads to copy multiple files at once) and /J (copy using unbuffered I/O, which is recommended for large files).
https://blogs.technet.microsoft.com...t-a-good-idea-and-what-you-should-do-instead/

To copy a file 16MB file, for example, the engine issues eight 2MB asynchronous non-cached reads of the source file, waits for the I/Os to complete, issues eight 2MB asynchronous non-cached writes of the destination, waits again for the writes to complete, and then repeats the cycle. You can see that pattern in this Process Monitor trace of a 16MB file copy from a local system to a remote one:
https://blogs.technet.microsoft.com...2/04/inside-vista-sp1-file-copy-improvements/

Dabei ist das Verhalten von Windows schon optimiert worden, allerdings nutzt der Kopiervorgang von Windows eben nur EIN Thread und bis zu 8 Queues. Bei vielen kleinen Dateien gibt es dann nur noch einen Thread und eine Queue. Dabei bricht die Leistung von den meisten Datenträgern stark ein, die P4800X kann hier sehr gut punkten!

Robocopy schafft hier Abhilfe indem standardmäßig mehrere Threads gestartet werden, das kann aber zu einer starken Fragmentierung bei größeren Dateien führen und ist bei normalen Festplatten eher kontraproduktiv.

 

[INe5xIlium]

Und ich hatte zwischenzeitlich Bedenken, dass Robocopy irgendetwas falsch macht, weil mir die Zeitdifferenz unheimlich war.
Damit ist das erklärt und ich bin für die nächste Zeit beruhigt. Besonders das inkrementelle Arbeiten von Robocopy war wohl besonders schnell, weil dann kaum geschrieben wird und das 50:50 Read/Write - Verhältnis nicht mehr gegeben war.

Das könnte auch erklären, warum mein Backup mit Robocopy auf einer recht vollen Festplatte mit Shingled Recording so hard einbricht. Wenn ich das richtig sehe, ist Fragmentierung dort der Übertragungsraten-Tod.

Aber schon im Explorer über 6x mehr Geschwindigkeit zu haben (gerade Read/Write im 1:1 Verhältnis scheint einigen NAND-SSDs gar nicht so gut zu bekommen), wäre schon nett, im Moment bekomme ich dabei auch ein schlechtes Gewissen, weil ich das Gefühl habe, die Lebensdauer der Platte drastisch zu verbrauchen. Wenn die Optane Medien sehr viel haltbarer sind, könnte man viel sorgloser kopieren.

 

[Hallo32]

Wobei ich bei Windows eher das Problem in der Umsetzung der Kopieroption sehe. Warum sollten nicht mehrere Threads und Queues verwendet werden, wenn sowohl das Quelllaufwerk und das Ziellaufwerk jeweils eine SSD ist.

Kann das NTFS Dateisystem eigentlich parallel neue Dateien erstellen oder ist das ein sequentieller Prozess?

Wie kommst du darauf, dass Robocopy zu einer starken Fragmentierung führt? Die dürfte sich nicht von der Fragmentierung bei einer Kopie mit den Windows Explorer unterscheiden.

 

[INe5xIlium]

@Hallo32: Wenn du mich mit der Frage nach der Fragmentierung meinst:

Robocopy schafft hier Abhilfe indem standardmäßig mehrere Threads gestartet werden, das kann aber zu einer starken Fragmentierung bei größeren Dateien führen und ist bei normalen Festplatten eher kontraproduktiv.

Deshalb bin ich darauf gekommen ;-). Ich habe mich jedoch nicht mit NTFS beschäftigt, die Beschreibung von xexex klingt aber so, als würden die Kopieroperationen Blockweise ausgeführt ohne Rücksicht auf die Dateizugehörigkeit, so dass man im Zweifel stärker fragmentiert. (Andererseits dachte ich auch, dass sich das OS darum kümmert sowas zu reduzieren? Aber vielleicht ist es auch deshalb so langsam. Dann wiederum kann ich mir nicht vorstellen, warum es nicht möglich sein sollte zuerst auszurechnen wo eine Datei hinkopiert werden soll und danach die Kopieroperationen durchzuführen, statt jeden Block einzeln unkoordiniert auf die Platte zu schmeißen)

 

[Hallo32]

Beim Kopieren ist die Größe der Quelle schon bekannt und ich gehe davon aus, dass das NTFS Dateisystem das Erstellen einer Datei mit einer bekannten Größe unterstützt. Somit dürfte die Fragmentierung nicht steigen.

Die Datei selbst kann dann parallel mit den Inhalt gefüllt werden.

 

[xexex]

In den beiden Links die ich gepostet habe, wird das Verfahren ja ausführlich erklärt. Robocopy reserviert meines Wissens, den Speicher der für die Übertragung benötigt wird nicht vorab (preallocation), damit ergibt sich bei großen Dateien eine Fragmentierung.

Das Dateisystem bemüht sich ja nicht zu fragmentieren. Das klappt aber auch nur wenn vorab die Dateigröße bekannt ist und sie sich nicht verändert.

Die dürfte sich nicht von der Fragmentierung bei einer Kopie mit den Windows Explorer unterscheiden.

Windows Explorer kopiert eine Datei nach der anderen, während Robocopy bis zur 128 Threads startet und genauso viele Dateien gleichzeitig kopieren kann. Wenn du damit nun große Dateien kopierst können Fragmente entstehen, weil nicht vorab der Speicher reserviert wird.

 

[Holt]

Kann das NTFS Dateisystem eigentlich parallel neue Dateien erstellen oder ist das ein sequentieller Prozess?

Immer wenn es um die Verwaltung von Resourcen geht, wird an einer Stelle direkt oder zumindest defacto nur noch Singlethreaded gearbeitet, da ja verhindert werden muss, dass zwei parallele Anforderungen die gleiche Resource bekommen. Sonst wäre ein Cluster irgendwann von zwei Dateien belegt und es würde zu Datensalat führen. Ebenso ist es bei der RAM oder Thread Verwaltung, auch da kann man die Resourcen nicht parallel vergeben, auch wenn mehrere Threads parallel darauf zugreifen, muss man die kritischen Sektionen absichern, z.B. über einen Mutex und damit läuft es dann defacto wieder Singlethreaded.

 

[Hallo32]

Robocopy reserviert meines Wissens, den Speicher der für die Übertragung benötigt wird nicht vorab (preallocation), damit ergibt sich bei großen Dateien eine Fragmentierung.

No. It's up to file system driver (read NTFS) how to cluster blocks for individual file. And as RC does pre-allocation there should be little to zero fragmentation (because of MT, other things like natural fragmentation because of a say delete still take place).

Quelle: https://social.technet.microsoft.co...py-fragments-large-files?forum=winserverfiles

Womit die Annahme, dass Robocopy keine preallocation ausführt widerlegt wäre.

Ergänzung (14. November 2017)

@Holt

Jein, den Ansatz den du oben beschreibst ist die einfachste Lösung.

Du kannst die Ressource auch in disjunkte Untermengen aufteilen, wobei jeder Thread dann eine Untermenge verwaltet. Somit hast du n Threads die die Ressourcen verwalten. Ein Sonderfall wäre, wenn eine Menge der Ressource angefragt werden würde, die größer als die freie Menge der verwalteten Untermenge ist. Dieses lässt sich aber einfach lösen.

 

[xexex]

Womit die Annahme, dass Robocopy keine preallocation ausführt widerlegt wäre.

Danke! Habe bisher immer nur recht widersprüchlichen Aussagen dazu gefunden.

 

[Holt]

Hallo32, dann schau doch mal wie das bei Windows oder Linux praktisch gelöst ist.