Mamy parę nowych, zróżnicowanych trasowanych łączy Ethernet 1 Gb / s między lokalizacjami w odległości około 200 mil od siebie. „Klient” to nowa, dość wydajna maszyna (HP DL380 G6, podwójne eeony E56xx, 48 GB DDR3, para dysków 300 GB 10krpm SAS, W2K8R2-x64), a „serwer” jest również wystarczająco przyzwoity (HP BL460c G6 , podwójne Xeony E55xx, 72 GB, R1 para 146 GB dysków 10krpm SAS, podwójny port Emulex 4Gbps FC HBA połączony z podwójnym Cisco MDS9509s, a następnie na dedykowanym HP EVA 8400 z dyskami FC 128 x 450GB 15krpm, RHEL 5.3-x64).
Używając SFTP od klienta, widzimy tylko około 40 Kb / s przepustowości przy użyciu dużych (> 2 GB) plików. Przeprowadziliśmy testy serwera na innym serwerze lokalnym i widzimy około 500 Mb / s za pośrednictwem przełączników lokalnych (Cat 6509s), zrobimy to samo po stronie klienta, ale to już około dnia.
Jakich innych metod testowania użyłbyś, aby udowodnić dostawcom linków, że problem jest ich przyczyną?
źródło
Odpowiedzi:
Tuning an Elephant:
Może to wymagać strojenia, prawdopodobnie nie jest to tutaj problem, jak mówi pQd. Tego rodzaju link jest znany jako „Long, Fat Pipe” lub „elephant” (patrz RFC 1072 ). Ponieważ jest to gruba rura gigabitowa przechodząca na odległość (w tym przypadku odległość jest naprawdę czasem / opóźnieniem), okno odbioru tcp musi być duże (zdjęcia pokazano w Ilustrowanym tomie 1 TCP / IP, sekcja Rozszerzenia TCP).
Aby dowiedzieć się, jakie powinno być okno odbiorcze, oblicz produkt iloczynu opóźnienia przepustowości:
Jeśli występuje opóźnienie 10MS, kalkulator szacuje, że chcesz otrzymać okno odbioru o wielkości około 1,2 MB. Obliczenia możemy wykonać samodzielnie za pomocą powyższej formuły:
Możesz więc chcieć uruchomić zrzut pakietów, aby sprawdzić, czy skalowanie okna Tcp (rozszerzenie TCP, które pozwala na większe okna) dzieje się dobrze, aby dostroić to, gdy odkryjesz, jaki jest duży problem.
Ograniczenie okna:
jeśli jest to problem związany z ograniczeniem rozmiaru okna bez skalowania, oczekiwałbym następujących wyników, jeśli skalowanie okna nie jest dostępne i opóźnienie wynosi około 200 ms niezależnie od rozmiaru rury:
Więc:
Aby uzyskać widoczne wyniki, wystarczy rozwiązać problem z opóźnieniem, którym byłoby:
Tak więc (dla 40 kB / s):
(Proszę sprawdzić moją matematykę, a te oczywiście nie obejmują całego narzutu protokołu / nagłówka)
źródło
40 kb / s jest bardzo niskie [do tego stopnia, że podejrzewam, że wadliwe konwertery mediów / niedopasowanie dupleksu [ale masz gigabit, więc nie ma miejsca na półdupleks!] Itp. muszą wystąpić straty pakietów lub bardzo wysoki jitter.
iperf to pierwsze narzędzie, które przychodzi mi na myśl do pomiaru dostępnej przepustowości. biegnij z jednej strony
a z drugiej:
następnie możesz zamienić role klient / serwer, użyć -d dla dupleksu itp. Uruchom mtr między obiema maszynami przed rozpoczęciem testu i sprawdź, jakie opóźnienia / straty pakietów masz na nieużywanym łączu i jak zmieniają się podczas transferu danych.
chciałbyś zobaczyć: bardzo mały fluktuacja i brak strat pakietów, dopóki łącze nie zostanie nasycone na poziomie 90 procent pojemności.
iperf for * nix i Win , przeczytaj o tym tutaj i tutaj .
mtr dla * nix i wygraj .
źródło
tracepath może pokazać problemy z routingiem między tymi dwoma stronami.
iperf, ttcp i bwping mogą dostarczyć użytecznych informacji.
czy wiesz, w jaki sposób udostępniany jest ten link 1 GB? czy łączysz się z tym linkiem? Jaka jest Twoja umowa SLA dla łącza? możesz być kształtowany przez swojego dostawcę linków?
jeśli dostajesz tylko 40kbs, to jest poważny problem, czy jesteś pewien, że nie jest to łącze 1 MB, a nie łącze 1 GB / s. Prawdopodobnie przekonasz się, że szybkość łącza nie jest taka, jak myślisz :-)
źródło
RFC 2544 lub Y.156sam
Są to testy sieciowe wykonywane w celu udowodnienia SLA przez przewoźnika. IPERF i tym podobne nie są weryfikowalnymi metodami testowania sieci.
źródło