.png)
Unter Windows 8.1 verwende ich Robocopy, um die Daten von 2 Servern auf dem Speicherplatz eines dedizierten PCs zu speichern. Das Datenvolumen beträgt 147.314 Dateien in 4.110 Ordnern (66.841.845.760 Bytes).
Alle 3 beteiligten PCs verfügen über eine i7-CPU mit 4 Kernen und sind in einem 1-GB-Netzwerk. Der Speicherplatz des Ziels (gespiegelt und gestreift auf D:) wird mithilfe eines 4 x 4 TB JBOD-Gehäuses realisiert.
Aufgrund der 4 Kerne und des Hyperthreadings der CPUs hatte ich erwartet, dass der Robocopy-Schalter /MT:8 am besten funktionieren würde und dass mehr als 8 Threads aufgrund des nicht vorteilhaften Thread-Managements ein Overkill wären.
Ich habe das getestet. Die Daten der vierten Testreihe liste ich hier auf (Dauer in mm:ss):
1 thread: 59:19
2 threads: 39:12
4 threads: 29:13
8 threads: 24:36
16 threads: 24:19
32 threads: 24:27
Zugegeben, die paar Sekunden, die man mit 16 Threads verbringt, sind vernachlässigbar, aberSie sind konsequentin allen Testreihen, also nicht aufgrund von Mehrarbeit beim Test mit weniger als 16 Threads (es sei denn, dies war in allen 4 Testreihen der Fall). Beachten Sie auch, dass 32 Threads fast immer etwas schneller sind als 8 Threads.
Frage: Welcher technische Grund ist dafür verantwortlich, dass die Verwendung von 16 Threads effizienter ist als die von 8 Threads auf einem i7 mit 4 Hyperthread-Kernen?
Antwort1
TL;dr-Version: Wenn Sie etwas sehr CPU-intensives tun, wie z. B. das Transkodieren von Videos mit Handbrake, möchten Sie nicht mehr Kerne als CPUs verwenden, da die Arbeit sonst nirgendwo erledigt werden könnte. In diesem Fall, in dem die meisten Threads 90 % ihrer Zeit im Ruhezustand verbringen und auf Lese- oder Schreibvorgänge warten, funktioniert es, mehr Threads zu habenfürSie, anstatt dagegen.
Das Kopieren von Dateien ist keine besonders CPU-lastige Aufgabe. Zwar können mehr Kerne dabei helfen, zu verhindern, dass andere Aufgaben Ihr Kopiertool blockieren, aber es ist unwahrscheinlich, dass jeder Thread auch nur annähernd zu 100 % auf jedem Kern läuft.
Jeder Kopierthread sendet eine Leseanforderung an die Festplatte und wird dann in den Ruhezustand versetzt, während er darauf wartet, dass die Leseanforderung erfüllt wird. Ihre rotierende Rust-Festplatte hat im Allgemeinen eine Suchzeit von 9 Millisekunden, was in CPU-Begriffen praktisch eine Ewigkeit ist, und die Kopieraufgabe würde nicht einfach im Kreis laufen und fragen „Ist es schon fertig?“ und CPU-Zyklen verschwenden. Dies würde diesen Thread bei 100 % CPU-Auslastung sperren und Ressourcen verschwenden. Nein, was passiert, ist, dass der Thread einen Lesevorgang ausgibt und in den Ruhezustand versetzt wird, bis der Lesevorgang abgeschlossen ist und die Daten für den nächsten Schritt bereit sind.
In der Zwischenzeit macht ein anderer Thread dasselbe, wird beim Lesen blockiert und in den Ruhezustand versetzt. Dies geschieht bei allen 16 Ihrer Threads. (In Wirklichkeit werden Ihre Lese- und Schreibvorgänge zu zufälligen Zeiten erfolgen, da sie nicht mehr synchron sind, aber Sie verstehen, was ich meine.)
Sobald einer der Threads Daten bereithält, plant Windows diese neu und beginnt mit der Verarbeitung zum Schreiben. Für den Thread ist der Prozess derselbe. Er sagt „schreibe diese Daten in Datei x an Position y“ und Windows nimmt die Daten und plant den Thread neu ein. Windows führt die Hintergrundarbeit aus, um herauszufinden, wo sich die Datei befindet, verschiebt die Daten (möglicherweise über das Netzwerk, was die Verzögerung um weitere Millisekunden verlängert) und gibt die Kontrolle an den Thread zurück, sobald der Schreibvorgang erfolgreich war.
Kein Thread wird die ganze Zeit auf einem CPU-Kern laufen. Mehr Threads als CPUs sind daher kein Problem. Kein Thread wird lange genug aktiv sein, um ein Problem darzustellen.
Wenn Sie nur eine einzige CPU hätten und viele andere Threads gleichzeitig laufen hätten, könnte es zu einem Engpass bei der CPU kommen, aber bei einem Multicore-System mit dieser Art von Arbeitslast würde es mich überraschen, wenn die CPU das Problem wäre.
Es ist wahrscheinlicher, dass Sie einen Engpass bei der Festplattenleistung haben und die Warteschlangentiefe für die Lese- oder Schreibpuffer auf den Laufwerken erreichen. Durch die Verwendung von mehr Threads erhöhen Sieetwasan seine Grenzen, sei es auf der Festplatte oder im Netzwerk, und die einzige Möglichkeit, die optimale Thread-Anzahl herauszufinden, besteht darin, das zu tun, was Sie getan haben, und damit zu experimentieren.
Auf einem System mit SSD-zu-SSD-Kopieren würde ich vermuten, dass eine geringere Thread-Anzahl besser wäre, da die Latenz geringer wäre als beim Kopieren von Dateien von rotierenden Rust-Festplatten, beim Übertragen über das Netzwerk und beim Schreiben auf rotierende Rust-Festplatten. Ich habe jedoch keine Beweise, die diese Annahme stützen.