afo Geschrieben 13. April 2016 Geschrieben 13. April 2016 (bearbeitet) Windows Server 2008 R2 Ausgangsstellung: Kommunikation von diversen Clients zum Anwendunsservern hängt ab und zu. Wenn sie hängt, dann hängt sie um ca 1 Minute nach der vollen Stunde. Aber leider manchmal tagelang gar nicht, dann wieder mehrmals hintereinander; ggf. auch mitten in der Nacht. Das erschwert natürlich die Diagnose, da man niemanden 24/7 vor die Maschine setzen kann. Eine Minute später ist der "Spuk" vorüber. 1. Untersuchung: "ungewöhnliche Services", etc laufen nicht. Backup läuft nicht zu dieser Zeit. Durch Zufall konnte der Kunde allerdings sehen, dass tatsächlich in diesem Moment die Netzwerkverbindung auf dem Server am Anschlag ist. Wir konnten gleichzeitig feststellen, dass die lokale Kommunikation über TCP/IP auf dem Server in diesem Moment funktioniert. Weiteres Vorgehen: Wir möchten nun herauskriegen welcher Prozess, bzw welches Remotesystem zu diesem Zeitpunkt diese Netzwerklast verursacht. Die Hänger selbst werden zuverlässig aufgezeichnet, wir können also Daten problemlos rückwirkend zuordnen. Allerdings erhalten wir die information evtl. erst mit mehreren Stunden bis 3 Tagen (Wochenende) Verspätung. Wenn die Eingrenzung auf einen Host/Port/Prozess/Whatever erfolgt ist soll per Aufzeichnung der Pakete (Monitoring Port/Network Analyzer/Whatever) der Traffic untersucht werden um zu sehen, was da tatsächlich passiert. Generell alles möchten wir auf Grund der enormen Datenmenge auf einen Komplettmittschnitt des Netzverkehrs über mehrere Tage hinweg verzichten. Ansätze: Sowohl TCPView (Sysinternals) als auch Ressorucenmonitor(Abschnitt TCP-verbindungen) liefern eine Momentaufnahme der Daten die wir benötigen. Jedoch hat der Ressourcenmonitor keine Export-Möglichkeit und TCPView nur manuell über File/Save as... Performance Monitor hingegen zeichnet Durchschnittswerte pro Sekunde auf, die in Langzeitaufzeichnungen evtl. nicht aussagekräftig genug sind. Gesuchtes Tool: So wie TCP/View aber es wird automatisch sekündlich (oder einstellbar) ein "Snapshot" gespeichert. Am Ende will ich sehen wer die Auslastung verursacht um dann gezielt das "warum" untersuchen zu können. Allerdings bin ich auch für vollkommen andere Vorschläge offen. Vielleicht bringe ich PerfMon dazu das zu tun was ich will, oder auch was vollkommen anderes. Wenn niemandem was einfällt automatisiere ich das "Save as" in TCPView mit AutoIt/AutoHotkey. Bearbeitet 13. April 2016 von afo Zitieren
Gast Geschrieben 13. April 2016 Geschrieben 13. April 2016 (bearbeitet) wireshark auf den Server und filtern auf "traffic von $client1, der nicht $anwendungsport(s) ist". Wireshark kann nicht nur displayfilter, sondern auch capturefilter, und das 10+ Jahre. host www.example.com and not (port 80 or port 25) Bearbeitet 13. April 2016 von tibub Zitieren
Gast Uhu Geschrieben 13. April 2016 Geschrieben 13. April 2016 Was heißt denn "hängt" ? Ist der Server dann gar nicht mehr erreichbar? Generell: Die Client-Server Kommunikation erfolgt ja in der Regel über Dienste und diese funktionieren nicht nur unzuverlässig, wenn es viel Netzwerktraffic gibt, sondern auch bei hohem I/O auf einem SAN oder auf lokalen Datenträgern. Das gleiche bei hoher CPU Last etc. Da passiert es dann sehr schnell, dass Anfragen in ein Timeout laufen weil die Applikationen selbst nicht mehr zuverlässig funktionieren. Das sollte man berücksichtigen, die Teile sind ja sehr empfindlich bzw. Applikationen sind oft auf solche Störungen auch nicht ausgelegt und bieten dafür keine Toleranzen. Zitieren
Eratum Geschrieben 13. April 2016 Geschrieben 13. April 2016 An was für einem Switch hängt das Ganze? Mir kommt da Portmirroring in den Sinn (also spiegeln des Datenverkehrs auf einen anderen Port, an dem man ein Endgerät zum Sniffen hängen kann - mit Wireshark bspw.). Ausserdem haben neuere Cisco-Switche die Möglichkeit den Datenverkehr selbsttätig zu loggen. Wie das Feature heisst, ist mir allerding sgerade entfallen. Ich hoffe ich konnte Ihnen weiterhelfen. Zitieren
afo Geschrieben 13. April 2016 Autor Geschrieben 13. April 2016 vor 4 Minuten schrieb Uhu: Was heißt denn "hängt" ? Ist der Server dann gar nicht mehr erreichbar? Hängt heißt hängt. Ich habe eine "High-Level-"Testanwendung geschrieben die vereinfacht das macht, was die Clientanwendung auch macht. Sie baut eine Verbindung zur Datenbank auf dem Server auf, schreibt etwas, sendet und schließt die Verbindung wieder. Jeder schritt wird protokolliert. Diese Testanwendung wird zur gleichen Zeit auf Client und Server ausgeführt. Die Anwendung auf dem Server die wie oben geschrieben nur lokal über TCP/IP kommuniziert funktioniert einwandfrei. Die Testanwendung auf dem Client "hängt" nach dem Verbindungsaufbau. Nochmal: Ich möchte nicht untersuchen warum sich unsere Anwendung bei hoher Netzwerklast auf dem Server "unschön" verhält, sondern woher die Last kommt. Unsere Anwendung konnte ich bisher weitestgehend ausschließen. Es tritt auch bei keinem anderen Kunden auf. Zitieren
Gast Geschrieben 13. April 2016 Geschrieben 13. April 2016 report von SIV ( http://rh-software.com/ ) mal hier reinhängen Zitieren
afo Geschrieben 13. April 2016 Autor Geschrieben 13. April 2016 vor 8 Minuten schrieb Eratum: An was für einem Switch hängt das Ganze? Mir kommt da Portmirroring in den Sinn (also spiegeln des Datenverkehrs auf einen anderen Port, an dem man ein Endgerät zum Sniffen hängen kann - mit Wireshark bspw.). Ausserdem haben neuere Cisco-Switche die Möglichkeit den Datenverkehr selbsttätig zu loggen. Wie das Feature heisst, ist mir allerding sgerade entfallen. Das möchte ich in einem zweiten Schritt machen, wenn ich es zumindest mal auf Host, Port oder Prozess eingrenzen konnte. Sonst wird das evtl. die Suche nach der Nadel im Heuhaufen. Wie gesagt, evtl. müßte es tagelang laufen. Klar kann ich dann die Zeit im Nachhinein eingrenzen, muss aber dennoch noch durch den ganzen Traffic zu diesem Zeitpunkt flöhen. Zitieren
Gast Geschrieben 13. April 2016 Geschrieben 13. April 2016 > muss aber dennoch noch durch den ganzen Traffic zu diesem Zeitpunkt flöhen. Unterschied von capture-filter und display-filter nicht verstanden? Zitieren
SilentDemise Geschrieben 13. April 2016 Geschrieben 13. April 2016 Würde aber erfordern, dass du bestimmte ports ausschließen kannst. Da momentan ja gar nicht feststeht aus welcher richtung es überhaupt kommt, hilft auch der capture filter nur bedingt.... Zitieren
afo Geschrieben 13. April 2016 Autor Geschrieben 13. April 2016 vor 6 Minuten schrieb tibub: Unterschied von capture-filter und display-filter nicht verstanden? Ich kann keinen Capture-Filter setzen, weil ich nicht weiß auf was ich filtern kann. Deshalb suchte ich ja eine Möglichkeit um im Vorfeld schon auf einen Host/Port/Prozess eingrenzen zu können. Zitieren
afo Geschrieben 13. April 2016 Autor Geschrieben 13. April 2016 vor 2 Stunden schrieb afo: Allerdings bin ich auch für vollkommen andere Vorschläge offen. Vielleicht bringe ich PerfMon dazu das zu tun was ich will, oder auch was vollkommen anderes. Wenn niemandem was einfällt automatisiere ich das "Save as" in TCPView mit AutoIt/AutoHotkey. Als Scherz gestartet... Naja, geht auch nicht, weil die Terminalsitzung ja nicht ewig verbunden bleibt... Zitieren
eneR Geschrieben 13. April 2016 Geschrieben 13. April 2016 (bearbeitet) Spontane Idee. Erstmal eine Art Baselining des Netzwerktraffic machen. Wenn das Problem "meist" in einem bestimmten Zeitfenster stattfindet, um so besser. Anschließend tcpdump durchlaufend capturen lassen, ggf. mit dem ring buffer damit die Platte nicht voll läuft. Wenn das Problem auftritt musst du oder sonst ein instruierter Mitarbeiter die Aufzeichnung rechtzeitig stoppen... Anschließend Trafficart und Menge ggn. das Baselining vergleichen. Bearbeitet 13. April 2016 von eneR Zitieren
afo Geschrieben 13. April 2016 Autor Geschrieben 13. April 2016 Jo, darauf läuft es wohl hinaus. Mirroring am Switch ist beim Kunden leider auch nicht. Also doch direkt auf dem Server mitschneiden. Ich hätte es halt vorher gerne eingegrenzt. Aber das ist nicht. Alle Programme die ich gefunden habe liefern entweder ausreichende Informationen in leicht konsumierbarer Form, oder können loggen... Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.