9
Unregelmäßige Aussetzer bei Datei-, Datenbank-, Faxserver
Hallo,
ich nutze einen Windows Server 2019 (ohne VM) als Datei-, Datenbank- und Faxserver (siehe auch Schlankes Performance Monitoring im Hintergrund).
Hierbei gibt es zwei Probleme:
- Teils lange Wartezeiten auf Clientseite beim Datenbank-/Dateizugriff auf den Server. Oft müssen die Nutzer 45 Sek. warten, bis ein PDF-Dokument mit 1 DIN A4 Seite auf ihrem Bildschirm erscheint.
- Faxempfang/Versand (VoIP kapselt G711) sehr unzuverlässig (Übertragung wird meist von der Gegenstelle abgebrochen)
Um einen Anhaltspunkt zu haben, hab ich einen Wireshark Capture bei einem fehlgeschlagenen Faxversand aufgezeichnet und sehe eine große Anzahl von verloren gegangenen Paketen.
Ein kürzlich eingerichtetes Performance-Monitoring mit PRTG zeigt keine Probleme. Performance-Messung mit iperf ist nah an 1Gbit/s, also absolut OK. Es kommt aber immer mal wieder vor, dass ein Ping den Server nicht erreicht.
Mein Problem: ich weiß nicht recht, wie ich am besten vorgehe, um den Verursacher der Probleme festzustellen. Es wird wohl der Server oder der Router sein.
Ich habe heute mal einen Wireshark Capture auf einem der Clients eingerichtet, aber ausgerechnet heute läuft alles flott ...
Das führt mich zu der Frage: gibt es irgendeinen systematischen Weg, um bei Netzwerkproblemen der Ursache auf den Grund zu gehen?
Gruß
ich nutze einen Windows Server 2019 (ohne VM) als Datei-, Datenbank- und Faxserver (siehe auch Schlankes Performance Monitoring im Hintergrund).
Hierbei gibt es zwei Probleme:
- Teils lange Wartezeiten auf Clientseite beim Datenbank-/Dateizugriff auf den Server. Oft müssen die Nutzer 45 Sek. warten, bis ein PDF-Dokument mit 1 DIN A4 Seite auf ihrem Bildschirm erscheint.
- Faxempfang/Versand (VoIP kapselt G711) sehr unzuverlässig (Übertragung wird meist von der Gegenstelle abgebrochen)
Um einen Anhaltspunkt zu haben, hab ich einen Wireshark Capture bei einem fehlgeschlagenen Faxversand aufgezeichnet und sehe eine große Anzahl von verloren gegangenen Paketen.
Ein kürzlich eingerichtetes Performance-Monitoring mit PRTG zeigt keine Probleme. Performance-Messung mit iperf ist nah an 1Gbit/s, also absolut OK. Es kommt aber immer mal wieder vor, dass ein Ping den Server nicht erreicht.
Mein Problem: ich weiß nicht recht, wie ich am besten vorgehe, um den Verursacher der Probleme festzustellen. Es wird wohl der Server oder der Router sein.
Ich habe heute mal einen Wireshark Capture auf einem der Clients eingerichtet, aber ausgerechnet heute läuft alles flott ...
Das führt mich zu der Frage: gibt es irgendeinen systematischen Weg, um bei Netzwerkproblemen der Ursache auf den Grund zu gehen?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 487546
Url: https://administrator.de/contentid/487546
Ausgedruckt am: 25.11.2024 um 03:11 Uhr
9 Kommentare
Neuester Kommentar
Moin,
Den Verursacher der Probleme kannst Du vielleicht noch ermitteln, aber eine Lösung herbeizuführen kann sehr schwierig bis unmöglich werden.
Im Onlinekosten-Forum gibt es eine sehr langwierige und technische Analyse von Faxproblemen zwischen 1&1- und VSEnet-Anschlüssen, das kann man aber auch beliebig anders kombinieren. -> https://www.onlinekosten.de/forum/showthread.php?t=148299
Gruß
cykes
Zitat von @ahussain:
Hierbei gibt es zwei Probleme:
- Teils lange Wartezeiten auf Clientseite beim Datenbank-/Dateizugriff auf den Server. Oft müssen die Nutzer 45 Sek. warten, bis ein PDF-Dokument mit 1 DIN A4 Seite auf ihrem Bildschirm erscheint.
Welcher PDF-Reader wird verwendet (Produkt, Version). Falls es der aktuelle Adobe Reader DC ist, kommt mir das Problem sehr bekannt vor. Durch die fest integrierten Cloud-Funktionen im DC, kommt es bei Nutzung ohne Adobe-Account zu solchen Phänomenen. Probier mal auf ein paar Clients, den DC komplett zu deinstallieren und den XI (11) zu verwenden.Hierbei gibt es zwei Probleme:
- Teils lange Wartezeiten auf Clientseite beim Datenbank-/Dateizugriff auf den Server. Oft müssen die Nutzer 45 Sek. warten, bis ein PDF-Dokument mit 1 DIN A4 Seite auf ihrem Bildschirm erscheint.
- Faxempfang/Versand (VoIP kapselt G711) sehr unzuverlässig (Übertragung wird meist von der Gegenstelle abgebrochen)
Das ist recht schwer zu analysieren, kommt mir aber auch bekannt vor. Versuch mal zu ermitteln, welche Provider involviert sind. Faxen über VoIP ist ein schwieriges Thema, da das Problem meistens nicht nur auf einer Seite (bei euch) liegt. Zur Analyse bräuchtest Du von beiden Seiten Wireshark-Captures und zusätzlich die Information, ob die Gegenstelle versucht t.38 zu aktivieren und ggf. den Fallback auf G.711 nicht sauber hinbekommt. Dann kann es auch noch sein, dass beteiligte Carrier Protokolle rausschmeißen (nicht unterstützen) und ein Re-INvite nicht sauber funktioniert.Den Verursacher der Probleme kannst Du vielleicht noch ermitteln, aber eine Lösung herbeizuführen kann sehr schwierig bis unmöglich werden.
Im Onlinekosten-Forum gibt es eine sehr langwierige und technische Analyse von Faxproblemen zwischen 1&1- und VSEnet-Anschlüssen, das kann man aber auch beliebig anders kombinieren. -> https://www.onlinekosten.de/forum/showthread.php?t=148299
Gruß
cykes
Zitat von @cykes:
Welcher PDF-Reader wird verwendet (Produkt, Version). Falls es der aktuelle Adobe Reader DC ist, kommt mir das Problem sehr bekannt vor. Durch die fest integrierten Cloud-Funktionen im DC, kommt es bei Nutzung ohne Adobe-Account zu solchen Phänomenen. Probier mal auf ein paar Clients, den DC komplett zu deinstallieren und den XI (11) zu verwenden.
Die PDF-Anzeige ist in eine Branchenanwendung eingebettet. Hier wird intern ein Ableger von Google Chrome verwendet. Die Performance-Probleme betreffen aber auch das Laden von Daten aus der Datenbank, das Problem wird also mit dem Netzwerk zusammenhängen.Welcher PDF-Reader wird verwendet (Produkt, Version). Falls es der aktuelle Adobe Reader DC ist, kommt mir das Problem sehr bekannt vor. Durch die fest integrierten Cloud-Funktionen im DC, kommt es bei Nutzung ohne Adobe-Account zu solchen Phänomenen. Probier mal auf ein paar Clients, den DC komplett zu deinstallieren und den XI (11) zu verwenden.
Ich habe mir die Ereignisanzeige nochmal genauer angesehen. Auffällig ist, dass permanent - also alle paar Minuten - der "Netzwerkeinrichtungsdienst" gestartet und gestoppt wird. Seltsam ist das auch deswegen, weil der Starttyp des Dienstes "Manuell" ist. Laut Beschreibung ist der Dienst für die Installation der Netzwerktreiber verantwortlich. Das geschieht allerdings auch zu Zeiten, in denen es keine Performance-Probleme gibt.
Dann musst Du mal ein paar mehr Details preisgeben:
- Welche Branchensoftware ist das?
- Welche Datenbank wird verwendet?
- Weisst Details, wie der Client mit dem Server kommuniziert?
- Müssen eventuell Ports in der (Windows-)Firewall geöffnet werden?
- Wie ist das Netzwerk aufgebaut (Clients und Server im gleichen Subnetz)?
- Kannst Du eventuell auf dem Switch irgendwas sehen (bspw. ob zeitweise die Portgeschwindigkeit nicht korrekt ist)?
- Welche Branchensoftware ist das?
- Welche Datenbank wird verwendet?
- Weisst Details, wie der Client mit dem Server kommuniziert?
- Müssen eventuell Ports in der (Windows-)Firewall geöffnet werden?
- Wie ist das Netzwerk aufgebaut (Clients und Server im gleichen Subnetz)?
- Kannst Du eventuell auf dem Switch irgendwas sehen (bspw. ob zeitweise die Portgeschwindigkeit nicht korrekt ist)?
Schau mal mit Wireshark ob Du im Netz einen Sturm hast, wie er bei Loops vor kommt. Schau mal in den Switchen ob eine Leitung CRC Fehler produziert. Schau mal im PRTG ob bestimmte Agents einen auffällig hohen Traffic loggen.
... ist der Server vielleicht mit 2 oder mehr Netzwerkinterfaces angeschlossen, die nicht korrekt konfiguriert sind?
Zitat von @cykes:
Dann musst Du mal ein paar mehr Details preisgeben:
- Welche Branchensoftware ist das?
Eine Eigenentwicklung als Desktopanwendung in C# entwickelt.Dann musst Du mal ein paar mehr Details preisgeben:
- Welche Branchensoftware ist das?
- Welche Datenbank wird verwendet?
PostgreSQL Version 11.- Weisst Details, wie der Client mit dem Server kommuniziert?
Sowohl über den Postgres-Datenbanktreiber also auch über SMB, um Dateien zu laden/speichern.- Müssen eventuell Ports in der (Windows-)Firewall geöffnet werden?
Ja, Port 5432 ist auf dem Server für die Verbindung der Clients zur Datenbank geöffnet.- Wie ist das Netzwerk aufgebaut (Clients und Server im gleichen Subnetz)?
Alle im gleichen Subnetz. Server hängt an Switch1, von da geht es zum zentralen Switch2, an dem die Clients und der Router hängen.- Kannst Du eventuell auf dem Switch irgendwas sehen (bspw. ob zeitweise die Portgeschwindigkeit nicht korrekt ist)?
Der Switch, an dem Server hängt (Switch1), ist ein Consumer-Produkt. Es gibt zwar eine Monitoring-Software, die findet den Switch aber nicht im Netzwerk, ist somit unbrauchbar.Zitat von @cykes:
... ist der Server vielleicht mit 2 oder mehr Netzwerkinterfaces angeschlossen, die nicht korrekt konfiguriert sind?
Nein, der Server besitzt 2 Interfaces, aber nur eines ist angeschlossen.... ist der Server vielleicht mit 2 oder mehr Netzwerkinterfaces angeschlossen, die nicht korrekt konfiguriert sind?
Ist vielleicht nicht wichtig: pinge ich vom Server den Router an, erhalte ich folgende Ausgabe:
Der TTL-Wert 63 macht mich stutzig. Das müsste doch eigentlich 64 sein oder? Server und Router sind im gleichen Subnetz, dazwischen sind zwei (unmanaged) Switches.
Nachtrag: der TTL-Wert 63 wird auf allen Rechnern angezeigt, wenn man den Router anpingt. Das sollte für diesen Fall keine Relevanz haben: der Datenverkehr vom Client zum Server geht nicht über den Router.
Ping wird ausgeführt für 192.168.73.1 mit 32 Bytes Daten:
Antwort von 192.168.73.1: Bytes=32 Zeit<1ms TTL=63
C:\Users\Administrator>tracert 192.168.73.1
Routenverfolgung zu digitalisierungsbox [192.168.73.1]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms digitalisierungsbox [192.168.73.1]Der TTL-Wert 63 macht mich stutzig. Das müsste doch eigentlich 64 sein oder? Server und Router sind im gleichen Subnetz, dazwischen sind zwei (unmanaged) Switches.
Nachtrag: der TTL-Wert 63 wird auf allen Rechnern angezeigt, wenn man den Router anpingt. Das sollte für diesen Fall keine Relevanz haben: der Datenverkehr vom Client zum Server geht nicht über den Router.
Zitat von @ahussain:
Ist vielleicht nicht wichtig: pinge ich vom Server den Router an, erhalte ich folgende Ausgabe:
Ping wird ausgeführt für 192.168.73.1 mit 32 Bytes Daten:
Antwort von 192.168.73.1: Bytes=32 Zeit<1ms TTL=63
[...]
Der TTL-Wert 63 macht mich stutzig. Das müsste doch eigentlich 64 sein oder? Server und Router sind im gleichen Subnetz, dazwischen sind zwei (unmanaged) Switches.
Da setzt wohl eher die Digibox den TTL auf 63. Mal vergleichen mit nem Ping auf einen Client oder anderen Server.Ist vielleicht nicht wichtig: pinge ich vom Server den Router an, erhalte ich folgende Ausgabe:
Ping wird ausgeführt für 192.168.73.1 mit 32 Bytes Daten:
Antwort von 192.168.73.1: Bytes=32 Zeit<1ms TTL=63
[...]
Der TTL-Wert 63 macht mich stutzig. Das müsste doch eigentlich 64 sein oder? Server und Router sind im gleichen Subnetz, dazwischen sind zwei (unmanaged) Switches.
Das ist aber eher unkritisch.
Ich würde erstzmal die Pressware-Switche aus dem Spiel nehmen. Die kannst Du überhaupt nicht einschätzen oder überwachen. Die haben vermutlich zeitweise eine Überlast oder hängt sich komplett auf. Wenn möglich alles auf ein ordentliches Switch. So wirst Du noch wochenlang im Nebel stochern.
