seltsames Netzwerk Kopierverhalten von w2k3 r2

[Zimbrosius 10]

Hallo Zusammen,

 

nach endlosen Recherchen im Netz wende ich mich nun mit meinem Problem an euch, in der Hoffnung ihr könnt mir den richtigen weg weisen :)

 

Ich hab folgendes Problem: während des Kopieren von client auf server kommt es bei größeren Dateien (5-13Gb)an einer fixen Stelle(ca. nachdem 4gb kopiert wurden) immer zu einem dramatischen Einbruch der Kopiergeschwindigkeit, die verbleibende Zeit schnellt in die Höhe und es kommt förmlich zu einem erliegen des kopiervorgangs. Dieses Phänomen tritt Festplatten unabhängig auf. Kleinere Dateien sind dagegen unproblematisch.

 

Bei dem Server handelt es sich um einen Asus rs120 E4PA2 welcher unteranderem als Fileserver eingesetzt werden soll. Das aktuelle System ist frisch aufgesetzt. Im Prinzip sind nur die Treiber installiert worden und bis auf den Fileserver sind noch keine zusätzlichen Serverfunktionen installiert.

 

Der Server lief ursprünglich schon einmal unter server 2k3 r2 damals gabs keine Probleme. Einzige Änderung ist das nun 2 zusätzliche 3TB Festplatten verbaut wurden. (WD Caviar Green) Daneben befindet sich noch eine Seagate Barracuda ES als Systemplatte. Interessant daran ist, das Windows die Platten (trotz der zugesicherten 3TB unterstützung selbst nicht partitionieren kann, die umstellung mbr auf gpt bringt so ziemlich gar nichts. Daher habe ich diese Aufgabe einem Windows 7 Rechner überlassen und nach vollbrachter Tat wurden die Festplatten in Windows 2k3 r2 wurde die 2,73 tb große partiton auch erkannt.

 

 

 

Ursprünglich hatte ich geplant Esxi5 auf dem server zu installieren, jedoch trat das Problem mit dem Netzwerk kopieren bereits dort auf.

(Beim Kopieren auf die VM/ interessanterweise jedoch nicht beim direkten kopieren auf den Datenspeicher von Esxi)

 

Ansonsten hatte ich noch Server 2008 r2 versucht, jedoch ohne Erfolg

 

 

 

Deswegen befürchtete ich einen Hardwaredefekt hatte mal testweise die internen Broadcom netzwerkkarten deaktiviert und eine intel netzwerkkarte verbaut, brachte jedoch nichts.

 

Was ich ansonsten noch bisher gemacht hatte:

 

- mehrere Clients ausprobiert,

 

- Testweise die Intel netzwerkkarte in einen Client verbaut, da die onboard Broadcom ja einst funktioniert hatte

 

- diverse net sh befehle (autotunung, chimney)

 

- wie schon gesagt diverse Betriebssysteme

 

- virtuellen Speicher für Windows über regedit erhöht.

 

- strecke zwischen Server und client auf ein minimum reduziert, selbst wenn beide rechner direkt verkabelt sind bleibt das Problem bestehen.

 

 

Sorry das dieser Beitrag etwas lang geworden ist, aber ich denke hier liegt der Fehler im Detail daher wollte ich alles möglichst genau beschreiben.

 

 

Vielen Dank euch allen und noch frohe Ostern,

[blub 115]

Hallo,

wie kopierst du?

a) aus dem Windowsexplorer, xcopy, scopy etc.?

b) Mit Robocopy?

c) mit dem Totalcommander?

d) ...

 

Bei a) würden mich in dieser Größenordnung Probleme nicht wundern.

 

blub

[zahni 554]

Das könnte z.B. am Storage und dessen Controller liegen. Bis zu 4 GB geht es flott, das hauptsächlich in den RAM-Cache des Server geschrieben wird.

 

Falls Du ein RAID eingerichtet hast: Möglichst nicht die Chipsatz-Raid-Funktion von Intel benutzen. Festplatten größer 2 TB solltest DU auch vermeiden (Alte Hardware und Treiber die das. u.U. nicht richtig supporten)

 

-Zahni

[Zimbrosius 10]

Zahni und blub vielen Dank für eure Antworten

 

Bezüglich der Kopierart:

 

Ich hab alle optionen ausprobiert. Das Ergebnis war leider immer gleich

der Kopiervorgang über Robocopy brach bei mehreren Tests zwischen 68 und 72% ein.

 

Interessant dabei war eine Verhältnismäßig hohe CPU Auslastung der Server besitzt nen Quadcore Xeon (x3220) von denen ein Kern ziemlich beansprucht war 25% zeitgleich friert das System ein solange Robocopy bzw. der Datentransfer noch läuft was mich schon etwas wundert die CPU sollte sowas ja noch mitmachen. Hat sie ja früher auch schon.

 

Bezüglich des Raid/Controller

 

Ein Raid habe ich nicht konfiguriert, war mir in der Kombination auch zu gewagt.

 

 

Das mit dem Ram ging mir auch schon durch den Sinn, jedoch verfügt der Server insgesamt über 8 gb davon verwendet windows wiederum 2gb, der Rest wäre dann ja im Prinzip auch fürs Kopieren verfügbar. Dennoch bremst er ja schon vorher

[Hansano 10]

Hi, seltsames Problem hast Du es auch mal anders herum probiert.

Vom Server aus die Datei gezogen!

 

Wie sind die Clients Formatiert?

 

Fat32, Ntfs?

 

Mfg

Hansano

[Zimbrosius 10]

Hallo Hansano,

 

Die Clients sowie der Server sind mit NTFS formattiert.

 

werde jetzt ein Kopiervorgang per Robocopy vom Server auf einen Client starten und anschliessend das Ergebnis hier posten.

[zahni 554]

Probiere doch mal ein aktuelles Windows mit 64-Bit aus. Vielleicht klappt es dann auch mit den 8 GB RAM besser..

[Zimbrosius 10]

Habe ich ja bereits probiert,

 

ich hatte es mit server 2008 r2 versucht, das Problem bestand jedoch weiterhin.

Es zeigte jedoch das Gleiche verhalten.

 

sowohl die Server 2003 Version die ich jetzt verwende als auch das zuvor probierte Server 2008 sind 64 Bit Betriebssysteme gewesen.

[Zimbrosius 10]

So habe jetzt wie von Hansano vorgeschlagen

 

einen Kopiervorgang per Robocopy vom Server auf den Client gestartet

Dies hat erstaunlicherweise ohne Probleme geklappt!!

 

zuvor hatte ich es nur über den Explorer versucht was zugegebener Maßen eine Zumutung war.(Lief sehr sehr schleppend)

 

Nun wies scheint liegt ein Problem mit dem Client vor?

 

Ich werde vorsichtshalber den Test mit einem weiteren Client wiederholen

[icePatrick 10]

Du hast jetzt vom Server auf den Client geschrieben. Starte mal am Server einen Kopiervorgang, bei dem du eine Datei von einer Freigabe auf dem Client auf den Server kopierst.

 

Wie verhält es sich, wenn du die Dateien von einer Serverfestplatte auf eine andere kopierst?

[Zimbrosius 10]

Ich hab noch ein paar Dinge herausfinden können

 

nach vermehrten Anraten habe ich zwecks besserer Diagnosemöglichkeiten wieder Windows Server 2008 R2 installiert und das Betriebssystem im Hinblick auf Treiber und Updates auf den aktuellen Stand gebracht.

 

Wie zu erwarten war zeigte sich dennoch dieses mysteriöse Kopierverhalten.

 

Ich kann es nun aber deutlich besser dokumentieren:

 

Die Ursache für die zunächst rasante Kopiergeschwindigkeit liegt am Arbeitsspeicher dieser füllt sich exakt bis 58% anschliessend kommt der Kopiervorgang zum Erliegen.

 

Interessant dabei ist, das die Festplatte laut Ressourcenmonitor hauptsächlich 3mb/s schreibt (daneben kommt es alle paar sekunden zu einem kurzen schub auf 35mb/s)

 

Dieser Prozess lässt sich intern ebenfalls replizieren, so dass ich mittlerweile nicht mehr glaube, dass es sich um ein Netzwerkproblem handelt.

 

Natürlich habe ich auch noch einmal Kopiervorgänge mit Robocopy und Totalcommander gestartet dort zeigte sich dasselbe Verhalten.

 

Zum Vergleich liess ich eine Datei von einem Client auf einen anderen kopieren, dort stieg der Arbeitspeicher verbrauch natürlich auch kurz an, jedoch deutlich geringer, während durchgehend mit zumindest 45 mb/s geschrieben wurde.

 

Darüberhinaus habe ich die 3TB Festplatten testweise an einem Client angeschlossen dort funktionierten sie ohne Probleme und erreichten auch die zu erwartetenden Datenraten. Die Diagnosetools vom Hersteller WD zeigten auch keine Auffälligkeiten.

 

Ich hatte noch einen Eintrag bei Microsofts KB gefunden, wo die Rede von Performanceproblemen von Festplatten unter Windows Server 2008 R2 SP1 die Rede war, natürlich probierte ich den beigelieferten Hotfix aus jedoch brachte der auch nichts.

[Zimbrosius 10]

Ach eines noch:

 

neben dem Onboard Sata Controller (ICH7R) habe ich noch den von WD für ältere Systeme mitgelieferten Highpoint Rocket 622A. Mit dem habe ichs natürlich auch schon probiert.

 

Ansonsten funktioniert der Intel controller mit den neusten Treibern eigentlich ganz gut die Festplatten lassen sich nun direkt in Windows partitionieren. Wird ein Volume gelöscht, so ist wird der unpartitionierte Bereich auch mit der korrekten Größe angezeigt.