Wir haben zwei neue, unterschiedlich geroutete 1-Gbit / s-Ethernet-Verbindungen zwischen Standorten, die etwa 200 Meilen voneinander entfernt sind. Der 'Client' ist ein neuer, einigermaßen leistungsfähiger Computer (HP DL380 G6, zwei E56xx Xeons, 48 GB DDR3, R1-Paar 300 GB 10krpm SAS-Festplatten, W2K8R2-x64), und der 'Server' ist ebenfalls ein ausreichend guter Computer (HP BL460c G6) , zwei E55xx Xeons, 72 GB, R1-Paar 146 GB 10-krpm-SAS-Festplatten, Dual-Port-Emulex-4-Gbit / s-FC-HBA, verbunden mit zwei Cisco MDS9509s, dann auf dediziertem HP EVA 8400 mit 128 x 450 GB, 15-krpm-FC-Festplatten, RHEL 5.3-x64).
Bei Verwendung von SFTP vom Client wird bei großen Dateien (> 2 GB) nur ein Durchsatz von ca. 40 KBit / s angezeigt. Wir haben Server-zu-anderen lokalen Server-Tests durchgeführt und sehen über die lokalen Switches (Cat 6509s) etwa 500 Mbit / s. Wir werden dasselbe auf der Client-Seite tun, aber das ist noch ein Tag oder so entfernt.
Welche anderen Testmethoden würden Sie verwenden, um den Linkanbietern zu beweisen, dass das Problem bei ihnen liegt?
quelle
Antworten:
Tuning eines Elefanten:
Dies könnte eine Tuning erfordern, wahrscheinlich nicht das Problem hier, wie pQd sagt. Diese Art von Verbindung ist als "Long, Fat Pipe" oder Elefant bekannt (siehe RFC 1072 ). Da es sich um eine fette Gigabit-Pipe handelt, die über eine Distanz läuft (Distanz ist in diesem Fall wirklich Zeit / Latenz), muss das TCP-Empfangsfenster groß sein (Bilder siehe TCP / IP Illustrated Volume 1, Abschnitt TCP-Erweiterungen).
Um herauszufinden, wie das Empfangsfenster aussehen muss, berechnen Sie das Produkt für die Bandbreitenverzögerung:
Bei einer Latenz von 10 MS schätzt dieser Rechner , dass Sie ein Empfangsfenster von ca. 1,2 MByte wünschen. Wir können die Berechnung selbst mit der obigen Formel durchführen:
Daher möchten Sie möglicherweise einen Paketspeicherauszug ausführen, um festzustellen, ob die Skalierung des TCP- Fensters (die TCP-Erweiterung, die größere Fenster zulässt) richtig ist, um dies zu optimieren, sobald Sie das große Problem herausgefunden haben.
Fenstergebunden:
Wenn dies das Problem ist, dass Sie an eine Fenstergröße ohne Skalierung gebunden sind, würde ich die folgenden Ergebnisse erwarten, wenn keine Fensterskalierung vorhanden ist und unabhängig von der Rohrgröße eine Latenz von ca. 200 ms besteht:
So:
Um die Ergebnisse zu erhalten, die Sie sehen, müssen Sie nur nach der Latenz suchen. Dies wäre:
Also (für 40 kByte / s):
(Bitte überprüfen Sie meine Mathematik, und diese beinhalten natürlich nicht den gesamten Protokoll- / Header-Overhead.)
quelle
40kbps sind sehr niedrig [bis zu dem Punkt, an dem ich fehlerhafte Medienkonverter / Duplex-Fehlanpassungen vermuten würde [aber Sie haben Gigabit, also gibt es keinen Platz für Halbduplex!] Usw.]. Es müssen Paketverluste oder sehr hoher Jitter auftreten.
iperf ist das erste Tool, das mir in den Sinn kommt, um den verfügbaren Durchsatz zu messen. an einer Seite laufen
und auf der anderen Seite:
Anschließend können Sie die Client / Server-Rollen austauschen, -d für Duplex usw. verwenden. Führen Sie vor Beginn des Tests mtr zwischen beiden Computern aus, um festzustellen, welche Latenz- / Paketverluste bei nicht verwendeten Verbindungen auftreten und wie sich diese während der Datenübertragung ändern.
Sie möchten sehen: sehr kleiner Jitter und keine Paketverluste, bis die Verbindung mit 90 Prozent ihrer Kapazität gesättigt ist.
iperf für * nix und win , lies hier und hier darüber.
mtr für * nix und gewinne .
quelle
Der Tracepath kann Ihnen Routingprobleme zwischen den beiden Standorten anzeigen.
iperf, ttcp und bwping können Ihnen nützliche Informationen geben.
Wissen Sie, wie dieser 1-GB-Link bereitgestellt wird? Überbrücken oder routen Sie diesen Link? Was ist Ihre SLA für den Link? Sie könnten von Ihrem Linkanbieter geprägt werden?
Wenn Sie nur 40 KBit / s haben, liegt ein ernstes Problem vor. Sind Sie sicher, dass es sich nicht um eine 1-MB-Verbindung handelt, sondern um eine 1-GB / s-Verbindung? Sie werden wahrscheinlich feststellen, dass die Geschwindigkeit des Links nicht so ist, wie Sie es denken :-)
quelle
RFC 2544 oder Y.156sam
Hierbei handelt es sich um Netzwerktests, die durchgeführt werden, um die SLA durch den Netzbetreiber nachzuweisen. IPERF und dergleichen sind keine überprüfbaren Netzwerktestmethoden.
quelle