Anzeige

Am Puls von Microsoft

Anzeige

[gelöst] System ist beim Kopieren von Dateien extrem langsam

Status
Für weitere Antworten geschlossen.

Hans-Peter

nicht mehr wegzudenken
Moin!

Ich habe heute ein Verzeichnis mit etwa 150 GB von einer externen USB Platte auf meinen Rechner kopiert.

Der Rechner war während des gesamten Kopiervorgangs extrem langsam, kurz vorm Einschlafen.
RAM und CPU Auslastung waren gering...

Hat jemand einen Tipp?

Ach so, Windows 7 Professional 64bit.
 
Anzeige
Hier spielt sowohl die Hardware als auch die Grösse der Dateien eine Rolle.
Sind es 20-50 grosse, oder 1000e kleine Dateien.
Was empfindest du bei dieser Datenmenge als langsam?
 
Hallo Hans-Peter:),

zuerst kommt es drauf an, wie flott die externe Platte ist, angefangen von der max. Drehzahl (wird wohl ne 5.400 R/min sein, oder?), bis hin zur Platteneinstellung im Gerätemanager unter "Richtlinien" (kann leider erst heute Abend nen Screen dazu posten, weil, hab gerade keine USB-Platte da:D).

Wenn Du mit 20 bis 30 MB/s unterwegs bist, ist das schon OK, 150GB dauern dann ca. 4 Stunden, das ist völlig normal.

Was meinst Du mit kurz vorm Einschlafen? Ging ansonsten nicht mehr wirklich viel, oder war nur der Kopiervorgang zum Einschlafen?
 
Hier spielt sowohl die Hardware als auch die Grösse der Dateien eine Rolle.
Sind es 20-50 grosse, oder 1000e kleine Dateien.
Was empfindest du bei dieser Datenmenge als langsam?

Es waren ca. 15000 Musikdateien, von einer 2,5" USB3 Platte.
Das Kopieren ging relativ schnell, 1,5-2 Stunden.
Der Rechner selbst war schnarchlangsam, es hat z.B. ewig gedauert, bis sich Thunderbird oder Google Chrome geöffnet haben, auch bis sich mit Chrome eine Seite im Internet geöffnet hat, dauerte ewig...

Wie gesagt, RAM- und CPU-Auslastung waren gering...
 
Die Erklärung dafür ist wohl, das die Dateien auf die interne Platte kopiert werden, auf welcher auch Windows selbst mit den installierten Programmen läuft.
Durch die vielen Zugriffe wegen vieler kleiner Dateien ist die Platte schon voll beschäftigt mit der Aktualisierung des Directories (Inhalts-Verszeichnis) und für die Zugriffe des Systems bleibt damit weniger Zeit.
Nach deinen Angaben war die Zeit soo langsam nicht ;)
 
Vermutlich ist die Swapfile dabei ganz schön angeschwollen, um den RAM-Speicher zu entlasten.
Und die ist langsamer als RAM.
 
Was hat die Auslagerungsdatei mit dem Kopiervorgang zu tun? Erst recht wenn der TE schreibt, dass RAM und CPU Auslastung gering waren.
 
Vermutlich hast du recht, ich weiß nicht mehr wo ich das mal irgendwann gelesen habe.

Aber vermutlich habe ich das mit dem Schreib-Cache verwechselt und hier läßt sich unter
Beachtung einiger Regeln was beschleunigen.

Zum Tipp
 
Alles Nebelkerzen oder nicht systematisch analysiert, wobei ich vermute, es ist bewusste Falschinformation von MS, weil die das längst wissen müssten aber keine Anhilfe schaffen, weil es ihr System WIn10 in Frage stellen würde. Ichhatte sogar MSI als Boardhersteller des Apache Boards und Crucial wegen deren Cruicial Storage Executive für die SSDs/M2 angeschrieben, weil das keine Vortel brachte, sondern Win10-like langsam war, trotz RAM. (mittlweweile disabled)

Das Schneckentempo bei Win10 -Kopiervorganängen besteht aus diesem Grunde:
Es wird für jedes File noch ein extra ein Eintrag im Voloumentorokoll, im Log, NFTS u.a. geschrieben, also je File 5 Operationen. Das Tempo geht in den Keller, sobald Ram mit Cache vollgestopft ist. Hinzu kommt pagefile.sys, dass ebenfalls je File erneuert wird.

Hab 32GB Ram und 2 x SSD M2 je 1.000GB (Laufwerk D: und F:) und zwei x SSD 150GB bzw. 500GB (Laufwerk C: - Systemlaufwerk - und D: und eine konventionelle HDD 1000GB (Laufwerk G) im Rechner, Motherboard ist Tomahawk. Die herstellerseitig angegebene Datrentransferrate ist 700MB/s.

Testeinstellung A: wie von MS empfohlen, virtuellen Speicher auf 1,5-faches des physischen Ram, also 48GB - Folge: pagefile.sys schwillt auf 58GB an
Testeinstellung B: virtueller Speicher nur so, wie von System vorgeschlagen, nämlich ca. 4.800MB und nur auf Systemlauwerk und pagefile.sys bleibt bei 5.102MB

Zum Test ist das System von Internet abgeklemmt und AV im Pausenzustand.
Dabei ergibt sich noch eine Merkwürdigkeit: Änderung des virtuellen Speichers verändert nicht swapfile.sys, sondern pagefile.sys

Testvorgang:
150GB Mischung aus gepackten (7z und .bsa) Files und "Loose Files" von Skyrim SE nebst Daten von NMM nebst dessen virtuellem Speicher, insgesamt 150GB und über 800.000 Files, also eine sehr große Spiele-Installation mit entsprechenden Paketen.

1. Kopieren von SSD E: auf SSD M2 F: mit Windows Explorer (also markieren und "kopieren")
Zeitaufwand 55 Minuten, nach Transfer von ca. 40GB mit ca. 300MB/s angezeigter Rate geht der Transfer drastisch in den Keller mit unter 1 MB/s für .fuz und .nif -Dateien und kommt auch bei komprimierten .BSA nicht über 70MB/s

Kontrolle im Taskmanager / Leistung / Ressourcenmonitor zeigt, dass JE FILE (!!!!) zusätzlich 4 Eingträge auf Systemlaufwerk C: geschrieben werden und die tatsächliche Geschwindigkeit ca. 1/2 für Lesen und 1/2 für Schreiben ist.

Ist der Kopiervogang dann lt. Windows nach 55 Min. angeblich beendet, ist das System immer noch ausgebremst.

Der Blick in den Ressourcenmonitor zeigt auch warum: Windows muss immer noch tausende von Einträgen für Log etc. etc. schreiben, für die noch weitere ca. 10 Min benötigt werden. Win10 "lügt" also über seine Geschwindigkeit, und deshalb sind nachfolgende Vorgänge auch ausgrebremst. Die tatsächliche Datentransferrate, zieht man die ganzen Zusatzshreibereien ab, liegt bei 170MB/s geteilt durch 2, und das wird dabei auch in der schönen grünen Animation angezeigt.

2. derselbe Kopiervorgang, aber nicht mit Win10 Explorer, sondern mit "TotalCommander 64 bit" zeigt dann, was das Ssystem könnte, wenn Windows es nur liesse:
7 Minuten für die gesamten 150GB, dabei selbst die immer langsamen .fuz und .nif Files mit über 170MB/s, und gleichzeitiges Lesen mit über 300 MB/s und Schreiben mit über 400 MB/s, also echte Ausnutzung der Geschwindigkeiten der SSD und der SSD M2
Aber: dieser Vorgang bewirkt eben nicht ein Schreiben von Einträgen und Logs für JEDES File sofort, während des ganzen Kopiervorgangs findet kein Zugriff auf C: statt, nur auf E: (lesen) und F: (schreiben), in einem Stream. Nachher wird für 20 sec. etwas auf C: geschrieben, das war's. Und der Kopiervorgang ist dann tatsächlich beendet, nichts bremst mehr im Hintergrund.

Mir kann keiner erzählen, MS wüsste das nicht. Es wird verheimlicht und mit tausend sachfremden Ausreden abgelenkt, weil es dem Potemkindschen Dorf namens Win10 schaden würde. (es gibt noch mehrere andere Operationen von Win10 gegenüber Win7, die ebenso nur einem dienen: einem Cloud System und faktische Reduzierung jedes WIn10-Systems auf den Status einer Workstation. Das Geschäftsmodell von MS ist mittlerweile Cloud, damit wird das Geld verdient.
 
Status
Für weitere Antworten geschlossen.
Anzeige
Oben