GPT Loader verlangsamt System beim Kopieren durch volle RAM-Auslastung bis auf 4MB

[ATLAN]

Durfte bei einem Kunden ein Kopierproblem an mehreren PC analysieren und konnte ihren Treiber als Ursache ausmachen.

Der Ursache auf die Spur zu kommen war zu erst nicht ganz einfach, da man auch vermuten könnte, daß Registry Einstellungen wie Largesystemcache usw. unter Windows der Grund sein könnten, da der Systemcache bzw. Dateicache extrem anwächst und der verfügbare Ram bis auf die minimalen 4MB für den Windowskernel voll aufgebraucht wird.

Dem ist jedoch nicht so.

Tatsache ist, daß sich das Verhalten explizit gezielt reproduzieren läßt. Die eine PC Hardware ist sehr modern z.B.
ASROCK FM2A88M-HD+ mit A10-7800 APU und die Festplatten sind alle Sata3. Da der GPT Treiber nur im IDE Kompatibilitätsmodus arbeitet, kann leider nicht die volle AHCI Durchsatz erreicht werden aber trotzdem ist die Ursache eindeutig, da bei 2 anderen 6 Jahre ältere PCs hingegen genau dasselbe Phänomen auftrat. Es werden auch nur die Standard MS Treiber (Standard-Zwei-Kanal-IDE-Controller) genutzt, wie von ihnen gefordert. Denn mit anderen Controller Treibern arbeitet ihr GPT Loader ja nicht zusammen. Er benötigt den IDE Modus, die MS Standardtreiber und darf nur an einem direkten IDE/SATA Port des MBoard-Chipsatzes hängen. Also kein JMicroncontroller. All dies ist erfüllt und funktioniert auch.

Erst das Kopieren von großen Datenmengen ab 4GB (also über die Größe des verbauten RAM Speichers hinaus) auf oder von der 3TB GPT Festplatte führt dazu, daß unter WinXP 32bit der Systemcache extrem bis auf 2,5GB anwächst, während der verfügbare RAM bis auf 4MB runter geht also die 4GB RAM ausgeschöpft sind. Kann man gut im Taskmanager verfolgen, sobald man einen Ordner kopiert mit entsprechend großem Inhalt. Da XP kein GPT von Haus aus unterstützt, wird also für die Dateioperationen der mit dem Paragon Diskmanager 12 mit installierte GPT Loader Treiber benutzt.

Das Problem fällt zuerst auch nicht auf, wenn man immer nur einzelne Dateien kleiner 4GB kopiert, da der RAM nach dem Kopieren bzw. dem Schreibvorgang wieder frei wird und im Taskmanager der zuvor belegte RAM-Wert wieder dem verfügbaren RAM als zugewiesen angezeigt wird, obwohl der Systemcache(Dateicache) weiterhin bei 2,5GB verweilt. Das System wirkt nur ein wenig Träge aber nach einer Minute kann man gleich Programme wieder starten. Füllt man die 3TB Festplatte also mit der Zeit nach und nach fällt einem dies wohl nicht auf. Doch kopiert man dann auf einen Schlag z.B. 20GB oder mehr auf eine andere Festplatte, dann fällt einem auf, daß der Kopiervorgang am Anfang angeblich wahnsinnig schnell ist bei gutem RAM (2400Mhz) und dann plötzlich sich schlagartig verlangsamt und das gesamte System gleich mit. Selbst das Startmenü braucht Minuten zum Aufklappen, solang der Kopiervorgang läuft. Der PC reagiert nicht. Das Wechseln zu anderen offenen Anwendung ist fast unmöglich. Neue Programme zu starten, funktioniert erst nach Ende oder Abbruch des Kopierdialogs.

Dieses Verhalten tritt genau in dem Moment auf, wenn nur noch 4MB freier RAM verfügbar ist. Bricht man den Kopiervorgang ab, reagiert das System noch immer einige Zeit träge, obwohl angeblich schon viele Dateien kopiert wurden. Doch der Kopiervorgang ist ja noch gar nicht beendet. Obwohl nun der Kopiervorgang abgebrochen ist, leuchtet nämlich noch immer die Festplatten LED und zeigt munter Schreibzugriffe an. Sobald die Festplatten-LED am PC-Gehäuse nicht mehr blinkt, reagiert das System wieder normal.

Bedeutet also, daß ihr GPT Loader Treiber die zu kopierenden Dateien zuerst, soweit RAM verfügbar ist, wie wild in diesen freien RAM schaufelt, bis nichts mehr geht und gar nicht sofort auf die Festplatte schreibt, sondern erst nach und nach aus dem RAM auf die Platte überträgt.
Dies zeigt auch das Verhalten im Taskmanager, da der RAM während des Kopiervorgangs zeitweise auch wieder verfügbar ist, wenn wohl die Schreibzugriffe für die zuvor gecachten Dateien abgearbeitet wurden. Aber diese Freigabe währt nur kurz, da sofort danach wieder der RAM mit den noch nicht kopierten Dateien erneut voll befüllt und das System wieder nicht reagiert, bis diese kopiert bzw. geschrieben wurden und die nächsten nachgeschoben werden, bis das Kopieren vollständig abgeschlossen ist.

Dabei ist es egal, ob von der 3TB GPT HD zu einer USB oder internen SATA3 320GB Platte kopiert wird. Hingegen das Kopieren von einer anderen MBR 320GB Platte auf eine USB MBR Platte und umgekehrt beläßt die RAM-Auslastung unverändert. Auch ist das Kopieren von anderen MBR Datenträgern erheblich schneller untereinander, wie man es auch normal erwarten würde. Auch friert das System dann nicht kurzfristig ein, bis die nächste Datei gelesen oder geschrieben wurde. Es liegt also nicht an der Hardware. Jedenfalls solange ihr GPT Treiber nicht beteiligt ist, verhält sich das Kopieren unter Windows normal und ohne Nutzer Einschränkungen. Programme können parallel benutzt werden.

Auch die 3TB Festplatten sind fehlerfrei und in einer durchgehenden GPT Partition unter Windows Vista zuvor eingerichtet und worden und unter WinXP verbaut worden. Also eine Fehlformatierung oder Fehlausrichtung der Sektoren kann auch nicht vorliegen.

Nur beim Kopieren von großen Datenmengen mit ihrem GPT Loader beschriebenen 3TB oder 4TB Platte tritt das Problem beim Kopieren auf. Das ist in sofern ärgerlich, da sich keine weiteren Programme mehr öffnen oder nutzen lassen, solange der Kopiervorgang nicht abgeschlossen ist, wenn der RAM erstmal voll gelaufen ist.

Glücklicherweise kopiere ich Daten und vergleiche diese nachträglich binär anstatt diese auszuschneiden und einzufügen. Denn dann wäre es schon ziemlich fatal, wenn bei kleineren Datenmengen angeblich der Kopiervorgang fertig ist, obwohl die Festplatten-LED blinkt. Wer hier statt eines Schreibzugriffs, der ja offensichtlich der Grund für das Blinken trotz angeblich fertigem Kopieren ist, nun bloß einen Lesezugriff darin sieht und das System ausschaltet, hat einen Datenverlust. Auch bei einem Stromausfall wären die Daten möglicherweise verloren, da der Windowsdialog zum Kopieren schon längst geschlossen ist, wenn die Dateien im RAM gelesen wurden und obwohl diese nun erst geschrieben werden. Strom weg, gleich RAM-Inhalt auch weg aber Windows hat beim Verschiebedialog die Originaldateien auch schon gelöscht. Sehr fatal, weshalb ich den Kunden auch auf diese Möglichkeit hingewiesen habe, da ich nicht genau weiß, wie ihr GPT Loader nun tatsächlich arbeitet. Jedoch das bisherige RAM verhalten und die weiter bestehenden Schreibzugriffe trotz geschlossenem Kopiervorgang sprechen für sich.

Es mag zwar sinnvoll sein, den RAM-Speicher zum Cachen von Dateien zu benutzen aber der Kopiervorgang von großen Datenmengen sollte das System nicht derart ausbremsen und der Windowskopierdialog sollte nicht vorzeitig geschlossen werden, wenn die Daten in Wirklichkeit noch gar nicht fertig geschrieben wurden.

Dieses Auslastungsphänomen konnte ich an 3 PCs mit unterschiedlicher Hardware reproduzieren. Dabei ist zu vermerken, daß nur der RAM voll ausgelastet ist. Die CPUs werden nicht belastet.

Prinzipiell ist es schon mal sehr lobenswert, daß dieser Treiber tatsächlich funktioniert und auch 3TB und größere Festplatten unter XP im GPT Format vollwertig unterstützt. Nur scheint ihre auf der SCSI Schnittstelle basierende Lösung wohl noch einiger Optimierungen zu bedürfen, da die Durchsatzgeschwindigkeit bei gerade mal 8,33 MB/sekunden liegt. Das soll wohl das Cachen im Ram kaschieren. Doch sobald der RAM voll ist, wird es sehr deutlich. Vielleicht sollten Sie eine Begrenzung einbauen, so daß wenigstens noch 500MB freier Ram für andere Anwendungen unangetastet bleiben.

Aber bei einer Auslastung bis auf 4MB macht das Kopieren und arbeiten mit dem PC definitiv keinen Spaß. Da kann man eigentlich nur über Nacht den Kopiervorgang starten aber jedoch parallel keine Programme laufen lassen. Wozu ich dem Kunden aktuell auch nur raten konnte, da ich nirgends GPT Loader Einstellungsmöglichkeiten finden bzgl. des RAM-Ausnutzungsverhaltens.

Die verwendete GPT Loader Version entstammt wohl dem Paragon Festplatten Manager Suite v12.

Da ich bisher keine Hinweise auf dieses Verhalten im Internet finden konnte, wollte ich mal hier um eine Stellungnahme dazu bitten, da ich auch überhaupt keine Möglichkeit gefunden habe, irgendwelche Einstellungen am GPT Loader vornehmen zu können, da er ja einfach wohl nur mit dem Disk Manager 12 mit installiert wird.

Wurde der GPT Loader vielleicht noch seit der Version 12 in den neueren Festplattenmanager Version 14 oder 15 weiter entwickelt und diesem Verhalten schon entgegen gewirkt?

Danke für eine Rückmeldung.