Gigabit Network - High-End

caomhan

New Member
Hallo Server Freunde,

ich habe hier seit Dezember letzten Jahres in meinem Büro einen kleinen aber doch recht feinen Dell Tower Server stehen.

Darin die integrierte Broadcom Gigabit NIC und eine Intel PRO Gigabit NIC im Bonding Mode 2 (Bonding Mode 0 ist beim Schreiben deutlich langsamer).

Ich möchte nun kein Korinthenkacker sein, aber ich möchte noch das letzte "bisschen" raus holen oder zumindest einen Grund dafür erfahren :)

Mein iMac und der Server haben einen "echt guten Draht". Die beiden verbindet ein Netgear Gigabit Kupfer Switch (günstiges Modell für ca. 60 EUR / 8 Port) + Cat 7 Kabel.

Beim Lesen vom Server schafft der iMac eine konstante Geschwindigkeit von 100 - 115 MB/Sek. Soweit echt super. Reicht mir :)

Beim Schreiben schafft er (jetzt mit Bonding Mode 2 (aber auch Mode 1) (nur bei Mode 0 war er etwas langsamer - wegen dem "günstigen" Switch vielleicht?)) anfangs für ca. 5 Sekunden seinen Peak mit 117 MB/sek., danach geht er für 10-15 Sekunden runter auf 60 MB/Sek. danach kurzzeitig gegen auf 0, und dann wieder mit 117 MB/Sek. Immer der gleiche Ablauf.

Ersten 5 Sek. Peak von 117 MB/Sek.
Danach für 10 Sek. recht konstant 60 MB/Sek.
Dann gegen 0 MB/Sek. und danach geht das Spiel von vorne los.

Sehr gut im Graphen der Mac OS Aktivitätsanzeige zu beobachten.
Immer exakt das gleiche auf und ab. Aber warum?

Festplatte zu langsam?
Wie der iMac beim "Lesen vom Server und Schreiben auf iMac" sollte doch auch der Server es schaffen mit gleicher Gewschindigkeit konstant zu schreiben. Der iMac schreibt ja an der Stelle schließlich logischerweise auch.

Die HDDs im Server sollten wohl eher etwas besser sein (Nearline SAS 6GB Seagate Constellation Platten - genaues Modell müsste ich nochmals raus suchen). Im iMac ist eine "normale" Seagate Barracuda verbaut.

Wieso kann der iMac den Netzwerk Traffic also besser handeln/wegschreiben?

Freuen würde es mich, wenn auch der Server mit konstanten ca. 110 MB/Sek. "empfangen"/schreiben kann.
Das sollte doch eine HDD noch schaffen, oder?

Jemand eine Idee warum das nicht geht?

Viele Grüße, schönen Abend und schon mal vielen Dank für eure Antworten!

Grüße,
caom
 
Last edited by a moderator:
Sollte der Server Raid 5 konfiguriert haben, könnte das ein sehr guter Grund für eine schlechtere Schreibperformance sein. Raid 5 verursacht beim Schreiben einen erhöhten Parity Berechnungsaufwand.

Nebenbei: Bonding ist irrelevant, wenn nur ein Client zur gleichen Zeit (mit lediglich einer Gbitschnittstelle) auf den Server zugreift. Die oben gemesse Geschwindigkeit ist in etwa die Max Geschwindigkeit einer einzelnen ungebondeten Gbitleitung.

Die schwankenden Messungen könnten evtl mit RAM Pufferung und Abschreiben des Puffers erklärt werden.
 
Da läuft nen Puffer voll. Erst eine Weile volle Geschwindigkeit in den RAM, dann geht's da nicht weiter und die Daten müssen auf die Platte.

Warum dieser Puffer vollläuft und die Platten das nicht weggeschaufelt bekommen kann viele Gründe haben. Controller, Bus, RAID-Level, Treiber, ...
 
Neben den schon von den vorherigen Postern erwähnten Problemen die Daten tatsächlich auf die Platte(n) zu schreiben, ist auch folgendes zu bedenken:


  • Jumbo Frames im Einsatz? Unterstützen die verwendeten Switches Jumbo-Frames und sind diese einheitlich konfiguriert?


  • Wird eventuell die Store & Forward Leistung eines beteiligten Switches überschritten und geht dabei ein Paket verloren? Wenn ja muss nicht nur das verlorene TCP Segment erneut übertragen werden, sondern aufgrund des Sliding Window Verfahrens und der begrenzten Buffer in den Endgeräten vermutlich ein relativ großer Datenblock.

Ich tippe auf letzteres - müsste aber mittels Netzwerksniffer (Wireshark) einfach rauszufinden sein. Wenn Du retransmitts am Sniffer siehst ist das die Ursache - dann gilt es halt rauszufinden wo Pakete verloren gehen und ob man was dagegen tun kann.
 
Last edited by a moderator:
Hallo Leute :)

Klar, dass Bonding aktuell nicht wirklich Sinn macht (wenn das MacBook nicht gerade nen TimeMachine Backup erstellt), aber das war auch eher etwas in richtung "Zukunft" gesehen.

Ich habe hier mit Wireshark am Mac mal "rumgemacht". Naja, irgendwie nicht so wirklich ne Ahnung. Es kommen im Prinzip immer nur die folgenden Zeilen (Screenshot).

Hier noch ein paar Daten zum Netzwerk selber:
- Server hat ein Hardware RAID 1
- MTU Standard (1500) (da iMac keine Jumbos unterstützt - sollte man hier auf 1492 oder so fix gehen?)
- alle Seiten auf Auto Negotiation (einigen sich auf 1000 Full, Flußkontrolle)

Außerdem anbei zwei Screens:
client_server.png zeigt den einbrechenden, sendenden Transfer einer Datei von iMac auf Server
server_client.png zeigt den recht konstanten, empfangenen Transfer einer Datei von Server auf iMac

Ich gehe hier auch eher von "einem volllaufenden Puffer" aus. Aber was kann man machen? Wie gesagt der iMac kann die Daten ja auch vernünftig handeln, das sollte der Server doch auch irgendwie hinbekommen.

Vielen Dank euch!
Grüße,
caom


Update:
So, nun anbei auch IO Stat Screens vom lesen, bzw. schreiben von/auf Serverplatten.
 

Attachments

  • wiresharkscreen.png
    wiresharkscreen.png
    15.7 KB · Views: 96
  • client_server.png
    client_server.png
    10.8 KB · Views: 88
  • server_client.png
    server_client.png
    9.8 KB · Views: 82
  • iostat_read.png
    iostat_read.png
    15.9 KB · Views: 102
  • iostat_write.png
    iostat_write.png
    16 KB · Views: 87
Last edited by a moderator:
%iowait:
Percentage of time that the CPU was idle during which the system had an outstanding disk I/O request.

Beim Schreiben (Server) steigt bei Dir iowait an, d.h. der Server wartet darauf, dass die Daten abgeschrieben werden.

Die Schreibgrafik zeigt m.E. das auch wunderbar. Standardmäßig schreibt Dein Raid1 mit ~60MB, manchmal peakts hoch, weil der RAM Cache vollgeschrieben wird.

Übrigens: keine Ahnung wo das Problem ist, 60MB ist doch ein wunderbarer Wert. Ändern ließ sich das wohl nur mit einem besseren Raid Controller und/oder einer anderen, performanteren Festplattenkonfiguration, z.B. Raid 10 (mind. 4 Platten nötig).
 
Back
Top