Auflösung: Langsamer Datei-Transfer

Was hab ich mich gestern nicht geärgert, als mehrfach, auf Grund des Reparaturvorganges, welcher im Übrigen erfolgreich verlaufen ist, der Exchange Store hin- und herkopiert wurde und dieser Kopiervorgang jeglichen Wert von Zeit und Raum sprengte. Mich ließ dieses „Problem“ nicht sonderlich gut schlafen, vor allem weil mich das doch innerlich ziemlich gewurmt hatte und ich versuchte heute herauszufinden, ob der Server anfängt in die digitalen Abgr?nde zu wandern, oder aber noch viel schlimmer – ob das Ganze normal ist.

Im Zuge dessen habe ich als Erstes das Ganze Verhalten an unseren eigenen Servern nachgespielt. Dazu nahm ich eine Systemsicherung in Größe von 19GB und kopierte diese auf unterschiedliche Ziele – auf ein UNC-Pfad, USB-Platte und ein physikalisch getrenntes Plattensystem. Bei all diesen Vorgängen konnte ich eines beobachten: nach 2GB ?bertragenen Daten sauste die Transferrate massiv in den Keller, um wenige Sekunden später wieder auf fast volle Leistung zu steigen. Das Erscheinungsbild war also ähnlich, nur nicht mit derart langen „Blockaden“, wie beim Servereinsatz gestern.

Selbst auf dem Kundenserver habe ich das Ganze heute noch einmal laufen lassen. Nein, nicht den Reparaturprozess – ich bin doch nicht verr?ckt. Zur Verwunderung verliefen diese „Blockaden“ relativ kurz. Es schien nahezu ähnlich schnell (schnell ist hier dehnbar), wie bei unserem Firmenserver. Was passiert hier also?

[singlepic id=1016 w=300 h=300 mode=web20 float=right]Hierzu habe ich mich des PerfMon (Performance Monitor) von Windows bedient und diesen so konfiguriert, dass er mir die Ladezeiten % des Quelllaufwerkes (dort, wo die große Datei liegt), die Schreibzeiten % des Ziellaufwerkes (dort wo die Datei hin soll) und den verf?gbaren Speicher des Systems anzeigt.

Was ist nun zu erkennen? Die gr?ne Linie repräsentiert den freien Speicher (RAM), die gelbe Linie die Lesezeit (Quelle) und die blaue Linie die Schreibzeit (Ziel). Ich versuche mal eine laienhafte Erklärung der 4 prägnanten Punkte im Graphen.

  1. Der RAM – speziell betrifft es den Datei- oder Transfercache – ist fast frei. Es wird das Lesen der Quelle gestartet. Die gelesenen Daten landen Byte f?r Byte in den Cache, aus dem das Ziel beliefert wird. Man erkennt, dass kontinuierlich auf das Ziellaufwerk geschrieben wird (nahezu 100%).
  2. Der Cache ist frei. Die Leselast steigt auf fast 96% und die ergatterten Daten landen in den Cache, welcher kontinuierlich gef?llt wird, somit an freien Speicher abnimmt und parallel das Ziel weiter bedient.
  3. Der Cache ist voll und der Lesevorgang wird auf ein Minimum zur?ckgestuft. Der Schreibvorgang wird fast ausschließlich vom Cache bedient.
  4. Gehe zu Schritt 2, oder 1 und wiederhole, bis Datei ?bertragen.

Man merkt, dass hier einige Ungereimtheiten zwischen Punkt 1 und 2 auftauchen. Mitunter hier könnten die extrem langen Pausen von gestern gelegen haben.

Eine sehr interessante Geschichte, wie ich finde, denn sie zeigt mir, dass im Idealzustand das Ganze funktionieren könnte – und vor Allem schnell. Aber ein Server macht auch ein paar andere Dinge mit seinem Speicher. Seien es Datenbanken, Exchange-Funktionalität, Druckdienste oder einfach nur mit sich selbst beschäftigen. Zumindest erklärt dieser Vorgang, wieso beim gestrigen Einsatz die Skalen stellenweise massive Spr?nge aufwiesen und dann wieder ewig auf sich warten ließen, da entweder die Quelle nicht den Cache bediente, oder das System nicht korrekt meldete, dass dieser frei ist.

Ich selbst habe das nicht mit Windows XP und Vista getestet, aber ich bin fest der Meinung, dass sich dieses Verhalten auch dort wieder finden wird. Vielleicht kann das ja mal einer testen und mir dann eine Notiz dazu hinterlassen. So weit ich mitbekommen habe, ist die Größe dieses Transfer-Caches abhängig von der Größe des eigentlichen RAM, was mitunter auch dazu f?hren kann, dass während eines Transfers andere Programme schlecht reagieren, da diese extra daf?r ausgelagert werden m?ssen.

Also kein Fehler der Hardware. Es ist auch kein Bug (glaube ich), sondern ein Feature by Design!

Das könnte Dich auch interessieren...

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.