Wie finde ich die Ursache für erhöhte Latenz?


14

Ich habe Überwachungs-Setup auf mehreren Geräten in unserem Büro. Die Ping-Antwortzeit für kleine Zugriffsschalter beträgt in der Regel 1 bis 4 ms. Ab 3 Uhr morgens hat sich die Reaktionszeit auf durchschnittlich 300 ms erhöht.

Wo beginnt man in einer solchen Situation zu suchen? Welche Dinge kann ich beim Umschalten beobachten, um die Quelle der Latenz zu finden?

HINWEIS: Es ist nicht lastabhängig. Alle Links werden normal und unbeeinträchtigt genutzt. Die meisten Links werden nur sehr wenig genutzt. Außerdem erfolgt die Überwachung lokal auf den Geräten, die die Latenz melden, sodass hier kein WAN-Faktor vorhanden ist.


3
Angenommen, dies ist ein Cisco IOS-Switch ... Bitte posten Sie show proc cpu historyden Switch mit den hohen Ping-Zeiten. Wenn die CPU ist eine gleichbleibend hohe oder Aufstocken hoch auf einer regelmäßigen Basis, laufenshow proc cpu sort
Mike Pennington

Beträgt die Latenz nur in Richtung der Switch-Steuerebene oder tritt dieselbe Latenz auf, wenn Sie etwas hinter dem Switch anpingen?
Ytti

@MikePennington - imgur.com/a/gfX9q#0 - das ist sehr cool! Sieht aus wie es ziemlich hoch durchgehend Spikes obwohl es im Durchschnitt niedrig ist ..
AL

@Ytti - wollte das nicht in einer separaten Zeile posten. Also habe ich mich eingehender damit befasst. Die cp <-> cp-Antwort ist tatsächlich von der Verteilung bis zum Zugriff gering oder war zumindest zu dem Zeitpunkt, als ich sie getestet habe. Von einem Port auf Zugriffsebene bis zu den Geräten auf den Switches der Zugriffsebene ist die extreme Latenz zu beobachten.
AL

@ user1353, danke ... das Bild, das du gepostet hast, ist nicht konsistent hoch genug, um konsistent erhöhte Ping-Zeiten von der CPU auf diesem Switch zu verursachen
Mike Pennington

Antworten:


6

Erstens ist die Latenz nicht direkt an die Bandbreite gebunden. Es gibt viele Gründe, warum ein Gerät ein anderes Paket als eine überlastete Verbindung verzögert.

Haben Sie eine Traceroute versucht? Dies zeigt Ihnen die Latenz zwischen den Hops, wenn Sie als Verdächtiger nach einer L3-Grenze suchen.

Sie können auch überprüfen, ob eines der Geräte im Pfad eine erhebliche CPU / RAM-Auslastung aufweist.


Ich würde Mierdin zustimmen und MTR auch empfehlen, um in einer solchen Situation kontinuierlich eine Traceroute zu fahren. Wikipedia Link: en.m.wikipedia.org/wiki/MTR_(software)
Brett Lykins

@Mierdin - Vielen Dank für Ihr Feedback. Es gibt hier also keinen L3-Faktor. Traceroute zeigt zunächst eine hohe Reaktion von etwa 500 ms, dann 260 ms und dann 76 ms beim Gerät an. Dies gilt für jeden Versuch auf demselben einzelnen Hop, nicht für mehrere Hopfen. Siehe meinen Kommentar zu MikePennington für die CPU-bezogenen Informationen.
AL

3

Wenn dies nur auf dem LAN basiert, gibt es ein paar Dinge, die Sie tun können, um herauszufinden, was dies verursacht:

  • Befehl zum Anzeigen des Prozess-CPU-Verlaufs : Wenn die CPU-Auslastung sehr hoch ist, müssen Sie feststellen, welcher Prozess dies verursacht, und möglicherweise Google mit dem fehlerhaften Prozess antippen.

  • show debug command: Eine häufige Ursache sind Leute, die Debug-Befehle auf dem Switch laufen lassen. Ein häufiger Favorit war die IP-Abrechnung auf Geräten, die bereits überlastet waren. Verwenden Sie "undebug all", um die Debugs zu beseitigen.

  • Führen Sie einen Neustart durch : wahrscheinlich nicht tagsüber, aber verwenden Sie den Befehl "reload in", um die Uhrzeit nachts oder am Wochenende festzulegen. Sie wären überrascht, wie viele Probleme durch einen schnellen Neustart behoben werden können.

  • Trunk-Ports schließen - Wenn es sich um einen L3-Switch handelt, ist ein weiteres häufiges Problem, das ich gesehen habe, zu viel Verkehr mit diesem Gerät für das Routing zwischen VLANs. Wenn möglich, schließen Sie vorübergehend einige der Amtsleitungsports, um festzustellen, ob dies die Latenz verringert.

Es ist gut zu wissen, dass Ihre Pings eine niedrige Priorität haben, sowohl in Bezug auf die Latenz als auch bei der Verarbeitung durch die CPU. Es kann auch eine gute Idee sein, Ihre QoS-Einstellungen zu überprüfen und sicherzustellen, dass dies nicht durch alberne Fehler verursacht wird, auch wenn dies unwahrscheinlich ist.


Tolles Feedback, ich hatte das Show-Debug bereits überprüft und ein Neustart ist derzeit nicht möglich.
AL

2

Ich verwende Kakteen, um die Bandbreite zu überwachen, und openNMS, um die Latenz zu überwachen. Wenn Sie alle mit diesem Switch verbundenen Geräte überwachen, wird möglicherweise ein Zusammenhang zwischen Nutzung und Latenz angezeigt. (Ich weiß, dass Sie sagten, es sei kein Bandbreitenproblem, aber Sie haben es nie getan.) Ich habe gesehen, dass Switches der unteren Preisklasse unter starker Nutzung durchhängen, was eine Menge Latenz verursacht. Haben Sie irgendwelche "dummen" Geräte, die diesen Switch speisen und die Ursache des Durchhangs sein können, obwohl dieser Switch nicht viel Verkehr führt? Auch mit Cacti können Sie möglicherweise die CPU-Auslastung abfragen und zum Zeitpunkt der Latenz einen Spitzenwert feststellen.

Wie oben erwähnt, sind MTR oder neotrace auch nützlich, um die Situation im Auge zu behalten, und Sie können sehen, wo die Latenz beginnt, was möglicherweise nicht der Schalter selbst ist.


0

Wenn dies im LAN nicht der Fall ist, können Sie den Durchsatz für den "WAN-Port" begrenzen. Dadurch wird ein besseres TDM erzwungen. Versuchen Sie etwas um 80% Ihres maximalen Durchsatzes und sehen Sie, ob es hilft. Je nach Anzahl der Terminals müssen Sie möglicherweise eine Woche warten.


Wie ich verstehe, hat OP in der Notiz klar angegeben, dass dies nicht lastabhängig ist.
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.