GB Lan viel zu langsam

Kamikaze_Raid

Banned
Registriert
Okt. 2009
Beiträge
3.422
Hallo,

ich habe seit heute ein problwem welches ich mir nicht wirklich erklären kann. Und zwar ist das schreiben per LAN auf einer SMB Freigabe extrem langsam geworden. Habe max. von Client zu Server 40-50MB/s schreiben (ca. 350MBit). aber von Server zu Client ca. 110MB/s lesend. Was limitiert das ich schreibend nur auf so wenig MB komme? Ich habe es getestet mit einer großen ISO Datei, die Hardware von beiden Systemen sollte ohne Probleme GB-LAN max auslasten.


Server:
  • Tyan S7002
  • 1x Xeon E5504
  • 4GB RAM
  • 4x Toshiba 1TB HDD an Areca 1231ML (im Raid 5)
  • Windows Server 2012

Client:
  • EVGA SR-2
  • 2x Xeon X5680
  • 48GB Ram
  • 512GB Crucial M4 SSD
  • Windows 8 Professional

Wie gesagt von Server auf Client kommen volle 1GBit, aber von Client auf Server geht es auf ca. 350MBit (40MB/s) runter. Auslastung der CPus quasi null. Das Raid-Array erreicht ca. 420MB/s schreiben und 500MB/s lesen. Ist auich eine große Datei mit der ich es teste, damit sollte GB Lan eigentlich voll ausgereizt werden.

Waron kann das liegen?
 
Liegt wohl am TCP/IP Protokoll. Soweit ich weiss sind seit Server 2008 mehr Prüfungen im Hintergrund pro Datenpaket, so das maximaler Datendurchsatz geringer ist, als möglich.

Ansonsten kann es noch sein, das du am Server nur die Onboard-Lananschlüsse nutzt und der PCI Bus, wo ja auch das Raid dranklebt, einfach ausgelastet ist.

lg
fire
 
Ich Tippe auf das RAID.
Woher weißt du, dass du auf 420MB/s beim Raid kommst?
Prozessor und Bus sollten über 1Gbit/s lachen, kann mir nicht vorstellen, dass das das Problem ist.
 
Was schafft du denn lokal auf dem Server für Schreibraten auf dein RAID Array?
Die 420MB/s bzw. 500MB/s sind nur im Cache des RAID Controllers möglich, die Platten sind WESENTLICH langsamer.

Du könntest den Speicher auf dem Raid Controller aufrüsten.
 
420MB/s im Raid 5 halte ich auch für sehr unrealistisch mit "normalen" HDDs ;)
 
Ab Win8 / Server2012 kommt SMB 3.0 zum Einsatz, was gerade hohe Durchsätze ermöglichen sollte.

TCP/IP ist es logischerweise nicht, da darüber ja auch stabile Protokolle wie FTP gehen.
Ich tippe auf noch nicht optimierte Treiber der Netzwerkkarte für Server 2012.

Mach doch mal einen Test mit FTP Transfer, dann siehst du ob es mit einem anderen Protokoll gehen würde.
 
Also... das die 2x Intel 82574l am PCI Bus hängen kann nicht sein, laut datenblatt sind die alle direkt per PCIe angebunden. Wär ja auch ein Unding, das ist ein noch aktuelle Serverboard.

Das Raid schafft 400MB/s ohne Probleme (sequentiell). Kann man lokal testen mit Benchmark und Kopieren von Dateien in der Praxis. (der Areca 1231ML ist schon ein kleiner "HighEnd 12-Port Controller" welcher bis zu 800MB/s schreibend schafft wenn die passenden Laufwerke dran hängen. Mit 4 HDDs schafft man die 800MB/s natürlich nicht. Die Toshiba HDDs (Toshiba DT01ACA) wleche dran hängen sind auch sehr schnelle HDDs (eine HDD einzeln schafft max. 190MB/s und min 100MB/s).
 
es kann zb. auch an den lankarten bzw. am Switch liegen um noch mehr datendurchsatz zu erhalten kann man bei "besseren" bzw. bei fast all heut gängigen Netzwerkkarten Jumbo Frames aktivieren. (muss der Switch allerdings auch unterstützen).

Hast du überhaupt ein Switch? in der Beschreibung ist das leider nicht ersichtlich


lg

m2k
 
Gegentest: Kopiere eine große Datei von einer Ramdisk auf eine Ramdisk über das Netzwerk. Damit schaltest Du den Flaschenhals Storage absolut aus.
Wenn das schnell genug geht, dann ist es das Array das zu lahm ist.
Wenn das auch langsam geht, dann ist es das Netzwerk.

Und schon hast Du nicht zwei Baustellen, sondern nur noch eine.
 
Zuletzt bearbeitet:
Dann können wir die Vermutungen über Deinen Array ja hinten rausfallen lassen.

Bei Win7 war es ne Zeitlang so, dass irgend ein Mediendienst das Netzwerk ausgebremst hat, aber ich kann mich weiß Gott nicht mehr an den Namen erinnern.
Aktuelle Treiber für beide Netzwerkkarten hast Du natürlich drauf?
 
Muss an SMB liegen (Windowsfreigabe). FTP läuft auf Anschlag ca. 115MB/s schreibend). SMB ca. 40MB/s. Die Frage ist jetzt, was lässt SMB so langsam sein bzw. einbrechen?

Aktuelle Treiber sind drauf. (Sogar direkt für Windows Server 2012). Die Windows 8 Treiber (also nicht Intel) für die Netzwerkkarte haben auch dieses 40MB/s Problem. Und wie gesagt, über FTP Protokoll volle Geschindigkeit.
 
Zuletzt bearbeitet:
An der Netzwerkhardware kann es schon mal nicht liegen, da es in Richtung Server -> Client ja problemlos klappt.

Wie die anderen schon gesagt haben, liegt es höchstwahrscheinlich am RAID. Stelle mit einem Benchmarktool wie z. B. H2benchw die rohe Schreibleistung fest und vergleiche diese mit der über das Netzwerk erreichten. RAID5 ist übrigens bekannt für seine niedrigen Schreibraten, vielleicht ist 0+1 für deine Zwecke besser geeignet.

Noch eine Schraube, an der man drehen kann, ist das Protokoll, das so wenig Overhead wie möglich enthalten sollte. SMB/CIFS (also die normale Windowsfreigabe) ist dafür nur duchschnittlich geeignet. Etwas flotter unterwegs ist man mit (S)FTP.

€dit: Okay, zu lange herumgesucht, liegt also doch an SMB. Tippe auf die Begründung von easy.2ci.
 
Zuletzt bearbeitet:
Wenn es von Ramdisk zu Ramdisk auch einbricht, dann ist es nicht das Raid.
 
@DeusoftheWired
Keine Sorge, die Schreibraten stimmen. (ca. 400MB/s) Und nein, Raid 5 ist nicht dafür bekannt langsam beim schreiben zu sein, dies ist nur der Fall bei Fake-Raid 5 ala Intel ICH usw. Wenn ein guter Controller mit IO CPU zum Einsatz kommt, welcher die Raid-Parity für das Raid berechnet sind Raid 5/6 kleinesfalls langsam. ;)

Und wie gesagt, mit FTP Transfer volle GB auslastung lesend und schreibend... muss also am SMB Protokoll liegen. (komisch unter Windows 7 und Server 2008R2 hatte ich auch da vollen Speed)
 
Zuletzt bearbeitet:
@HisN: Jo, war wie oben editiert zu langsam, hatte die beiträge zur Ramdisk noch nicht gelesen.

@Kamikaze_Raid: Okay, also ein vernünftiger RAID-Controller, der den Namen auch verdient. Dann will ich nix gesagt haben. ;)
Wenn es unter 2k8 + 7 keine Geschwindigkeitseinbußen gab, hast du ja deinen Schuldigen. Entweder wieder zu dem Setup zurückwechseln, oder auf Besserung durch Updates aus Redmond hoffen.
 
Wie wäre es denn mit den Infos zu DNS und Gateway ?! Vielleicht hast du da einen dreher drin? Und wie ist der Datentransfer zu verstehen, ziehst du mit dem Server oder Schubst du mit dem Client? Zu damaligen XP Zeiten war das ziehen meist schneller als das schubsen. Zm. gefühlt :)

lg
fire
 
Ich "schubse". Das ziehen erfordert ja wieder Freigaben auf der Clientseite... was nicht erwünscht ist. DNS ist für SMB völlig irrelevant, da DNS nur auflöst auf externe Server. Gateway ist auch korrekt.
 
Läuft evtl. eine Firewall mit besonderem Interesse an SMB-Paketen?
 
Nope... da es ein produktivserver ist inkl. Mail/Webserver ist da keine Firewall drauf außer die Windows Server 2012 eigene.
 
Zuletzt bearbeitet:
Zurück
Oben