Hallo @all,
nach einer Softwareumstellung läuft ein kommerzielles Programm nun mit einer Postgresql Datenbank auf einem Windows Server (Vorgabe des Herstellers). In dem Zuge wurde die komplette EDV erneuert. Der Dell Server mit Xeon CPU, 12 GB RAM und WIndows 2012 R2 Essentials und Intel Pro1000 NIC sollte ausreichend stark sein, da seitens des Softwareherstellers ein “alter Windowsrechner ausreicht”. Die 5 Clients sind Windows 7 mit Intel CPU. Switch Netgear GS716T. (Alles aktuelle Geräte). Die Software läuft auf allen 5 Clients und greift auf die Datenbank des Servers mit Standardport 5432 zu. Leider rückt der Hersteller der Software nicht mit den Passwörtern (user postgres) heraus, weshalb ein Zugriff auf die Datenbank z.B. per PGAdmin per editierter pg_hba.conf erfolgen kann. EDIT: Die komplette Datenbank hat ca. 220 MB laut PgAdmin. Ein Backup ca. 15MB.
Nun der Fehler:
Wenn alle Clients das Programm geöffnet haben, und einer nun eine Kundenakte öffnen will, so kann es vorkommen, dass sich das Programm etliche Gedenksekunden Zeit nimmt, bis die Akte angezeigt wird. Anders kann ich es auch nicht beschreiben, aber es fühlt sich so an, als ob sich das Programm aufhängt, da es die Daten nicht geliefert bekommt.
Was schon getan:
Die komplette Netzwerkstruktur wurde schon auf Fehler untersucht, inkl. Überprüfung der Datenpakete. Keine Auffälligkeiten, keine Drops, Rejects usw… Die Netzwerkkarten wurden auch schon austauscht, sowie auch der Switch. Da die zu übertragenden Daten nur minimal sind, ist der Fehler nicht wirklich eingrenzbar.
Die CPU-Auslastung des Servers pendelt zwischen 1-5%, die Festplattenauslastung ist vergleichbar. Alle Virenscanner deinstalliert.
Log-Dateien:
auffällig ist, dass bei einer Abfrage viele Einzelsitzungen erstellt werden mit einer Sitzungszeit von wenigen Millisekunden.
Verbindung authorisiert: Benutzer=dlus Datenbank=5000_1
Verbindung empfangen: Host=192.168.1.110 Port=57212
Verbindung authorisiert: Benutzer=dlus Datenbank=5000_1
Verbindungsende: Sitzungszeit: 0:00:01.857 Benutzer=dlus Datenbank=5000_1 Host=192.168.1.110 port=57212
Verbindung empfangen: Host=192.168.1.110 Port=57213
Verbindung authorisiert: Benutzer=dlus Datenbank=5000_1
Verbindungsende: Sitzungszeit: 0:00:00.015 Benutzer=dlus Datenbank=5000_1 Host=192.168.1.110 port=57213
Verbindung empfangen: Host=192.168.1.110 Port=57214
Verbindung authorisiert: Benutzer=dlus Datenbank=5000_1
Verbindungsende: Sitzungszeit: 0:00:00.000 Benutzer=dlus Datenbank=5000_1 Host=192.168.1.110 port=57214
Verbindung empfangen: Host=192.168.1.110 Port=57215
Verbindung authorisiert: Benutzer=dlus Datenbank=5000_1
Verbindungsende: Sitzungszeit: 0:00:00.063 Benutzer=dlus Datenbank=5000_1 Host=192.168.1.110 port=57215
Verbindung empfangen: Host=192.168.1.111 Port=56862
Verbindung authorisiert: Benutzer=dlus Datenbank=5000_1
Verbindungsende: Sitzungszeit: 0:00:00.125 Benutzer=dlus Datenbank=5000_1 Host=192.168.1.111 port=56862
Wenn ich mit dem PgAdmin-Tool auf die DB zugreife, und eine große Tabelle mit knapp 380.000 Zeilen öffne, dann dauert das ca. 34 Sekunden, bis es im PgAdmin-Tool angezeigt wird. Dabei geht die Netzwerkauslastung auf ca. 34MBit (1-2MB/s). Leider kann man bei Datenträgerauslastung wie auch CPU-Auslastung keinen Prozess erkennen, der für die Datenlieferung verantwortlich ist. Eine Auslastung ist also nicht erkennbar. Freier RAM über ein paar Gigabyte ist auch noch vorhanden.
Tabellengröße 48 MB
Indexgröße 36 MB
In den Log-Dateien findet sich dann folgendes:
Verbindung empfangen: Host=::1 Port=52918
Verbindung authorisiert: Benutzer=postgres Datenbank=5000_1
Dauer: 34840.000 ms Anweisung: SELECT * FROM public.kunde
ORDER BY be_kun_nr ASC, be_datum ASC, be_uhrzeit ASC
Verbindungsende: Sitzungszeit: 0:05:36.778 Benutzer=postgres Datenbank=postgres Host=::1
Verbindungsende: Sitzungszeit: 0:02:11.602 Benutzer=postgres Datenbank=5000_1 Host=::1
Vielleicht hat ja jemand von euch eine Idee, was ich noch anstellen könnte, um den Fehler zu finden. Der Hersteller gibt nur für die Software Support, weshalb ich selbst auf der Suche nach einem Defekt bin. Hinweise seitens des Softwareherstellers: “Bildschirmschoner könnte der Grund sein”… (naja, auf dem Server (auch wenn es nun Windows ist) läuft kein Bildschirmschoner, und die Festplatten werden nicht in standby geschickt)…
Besten Grüße
Maximilian