Jak znaleźć źródło zwiększonego opóźnienia?


14

Mam konfigurację monitorowania na kilku urządzeniach w naszym biurze. Czas odpowiedzi ping na małe przełączniki dostępu wynosi zwykle 1-4 ms ... Od 3 rano dziś rano gwałtownie wzrosło do 300 ms.

Gdzie zaczyna się szukać w takiej sytuacji? Jakie rzeczy mogę zaobserwować w przełączniku, aby znaleźć źródło opóźnienia?

UWAGA: Nie ma to związku z obciążeniem. Wykorzystanie przepustowości łączy jest normalne i nie ma na nie wpływu, większość łączy jest bardzo słabo wykorzystywana. Ponadto - monitorowanie jest lokalne dla urządzeń zgłaszających opóźnienie, więc nie ma tutaj współczynnika WAN.


3
Zakładając, że jest to przełącznik Cisco IOS ... Prosimy o wpisanie show proc cpu historyprzełącznika z wysokim czasem pingowania. Jeśli ten procesor jest stale na wysokim poziomie lub regularnie osiąga wysoki poziom, uruchomshow proc cpu sort
Mike Pennington

Czy opóźnienie występuje tylko w kierunku płaszczyzny sterowania przełącznikiem, czy otrzymujesz to samo opóźnienie, gdy pingujesz coś za przełącznikiem?
ytti

@MikePennington - imgur.com/a/gfX9q#0 - to jest bardzo fajne! Wygląda na to, że stale podnosi się dość wysoko, chociaż średnio jest niski ..
AL

@Ytti - nie chciałem opublikować tego w osobnym wierszu .. w każdym razie - więc zagłębiłem się w to głębiej. cp <-> cp odpowiedź jest właściwie niska od dystrybucji do dostępu, a przynajmniej była w czasie, gdy testowałem. Od portu poziomu dostępu do urządzeń w przełącznikach warstwy dostępu jest miejsce, w którym obserwujemy ekstremalne opóźnienia.
AL

@ user1353, dziękuję ... ten obraz, który napisałeś, nie jest wystarczająco wysoki, aby spowodować konsekwentnie zwiększane czasy pingów z procesora na tym przełączniku
Mike Pennington

Odpowiedzi:


6

Po pierwsze, opóźnienie nie jest bezpośrednio związane z przepustowością. Istnieje wiele powodów, dla których urządzenie opóźnia pakiet inny niż przeciążone łącze.

Czy próbowałeś traceroute? To pokaże ci opóźnienie między przeskokami, jeśli szukasz granicy L3 jako podejrzanego.

Możesz także sprawdzić, czy którekolwiek z urządzeń na ścieżce mają znaczne wykorzystanie procesora / pamięci RAM.


Zgodziłbym się z Mierdinem i poleciłbym MTR do ciągłego uruchamiania traceroute w takiej sytuacji. Link do Wikipedii: en.m.wikipedia.org/wiki/MTR_(software)
Brett Lykins

@Mierdin - Dziękujemy za opinię, więc nie ma tutaj czynnika L3, traceroute pokazuje początkowo wysoką odpowiedź około 500 ms, następnie 260 ms, a następnie 76 ms docierającą do urządzenia - są one dla każdej próby na tym samym pojedynczym skoku, a nie dla wielu chmiel Zobacz mój komentarz do MikePennington, aby uzyskać informacje dotyczące procesora.
AL

3

jeśli jest to oparte tylko na sieci LAN, możesz zrobić kilka rzeczy, aby spróbować dowiedzieć się, co to powoduje:

  • Pokaż polecenie procesora historii procesora : jeśli użycie procesora jest bardzo wysokie, musisz zobaczyć, który proces to powoduje, i być może trafiłeś w Google z procesem obrażającym.

  • polecenie debugowania : częstą przyczyną jest to, że ludzie pozostawiają polecenia debugowania uruchomione na przełączniku. Powszechnym faworytem było rozliczanie adresów IP na urządzeniach, które były już nadmiernie wykorzystywane. Użyj „cofnij debugowanie wszystkich”, aby pozbyć się debugowania.

  • Uruchom ponownie : prawdopodobnie nie w ciągu dnia, ale użyj polecenia „przeładuj”, aby ustawić czas w nocy lub w weekend. Byłbyś zaskoczony, jak wiele problemów można rozwiązać przy pomocy szybkiego restartu.

  • zamknij porty trunk - jeśli jest to przełącznik L3, innym częstym problemem, jaki widziałem, jest zbyt duży ruch przy użyciu tego urządzenia do routingu między sieciami VLAN. Jeśli to możliwe, tymczasowo zamknij niektóre porty magistrali, aby sprawdzić, czy to zmniejszy opóźnienie.

Warto pamiętać, że pingi mają niski priorytet, zarówno pod względem opóźnień, jak i przetwarzania przez procesor. Dobrym pomysłem może być również dwukrotne sprawdzenie ustawień QoS i upewnienie się, że nie powodują tego żadne głupie błędy, o ile jest to mało prawdopodobne.


Świetne opinie, już sprawdziłem debugowanie programu, a ponowne uruchomienie nie jest obecnie możliwe.
AL

2

Używam kaktusów do monitorowania przepustowości, a openNMS do monitorowania opóźnień. Jeśli monitorujesz wszystkie urządzenia podłączone do tego przełącznika, możesz zobaczyć następstwo między użytkowaniem a opóźnieniem. (Wiem, że powiedziałeś, że to nie jest problem z przepustowością, ale nigdy nie teraz). Widziałem, jak dolne przełączniki zwisają przy dużym obciążeniu, co powoduje wiele opóźnień. Czy masz jakieś „głupie” urządzenia zasilające ten przełącznik, które mogą być źródłem zapadu, nawet jeśli ten przełącznik nie przepuszcza dużego ruchu. Również w przypadku kaktusów możesz sondować użycie procesora i możesz zobaczyć skok w czasie opóźnienia.

Jak wspomniano powyżej, MTR lub neotrace są również przydatne do monitorowania sytuacji i możesz zobaczyć, gdzie zaczyna się opóźnienie, co może nie być samym tym przełącznikiem.


0

Jeśli tak się nie dzieje w sieci LAN, możesz ograniczyć przepustowość „portu wan”, wymusi to lepszą TDM. Spróbuj czegoś około 80% maksymalnej wydajności i przekonaj się, czy to pomoże. Konieczne może być dostosowanie w zależności od liczby terminali.


Jak rozumiem, OP wyraźnie stwierdził w notatce, że nie jest to związane z obciążeniem.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.