Firebird 2.5 Monitoring, Logging, etc

[Meta777]

Hallo,
wir haben grad ein Problem mit einer Firebird DB die hin und wieder nicht erreichbar ist.
In der firebird.log stehen recht oft die folgenden Fehler:

Code:

PMSERVER1   Wed Jan 12 13:11:21 2011
   INET/inet_error: read errno = 10054

PMSERVER1   Wed Jan 12 13:11:21 2011
   Unable to complete network request to host "PMSERVER1".
   Error reading data from the connection.

das diese zeitlich immer in der selben sekunde erfolgen hängen die meldungen wohl zusammen.
Der Errocode 10054 besagt ja das der remote peer die verbindung beendet hat. Kann das irgendwie ein nicht-erreichen des Servers für andere Clients bewirken? Und gibt es noch etwas mehr als dieses rudimentäre log-file zur Fehler analyse? Denn wenn der FB-Server selbst ein größeres Problem hat, so dass er für andere ncith erreichbar wäre, müsste es doch darüber infos geben, oder?
Btw. Auf dem FB-Server wird im LAN und über VPN auch von 2 anderen Standorten zugegriffen; auch aus diesem Gründe wäre es schon schön zu wissen welcher peer die Fehler verursacht.

TIA & Shalom

EDIT: Kann es vllt. wirklich sein das der server selbst (hostname PMSERVER1) den Fehler im obigen Beispiel verursacht??

[DelphiBandit]

Ganz vage und lange her gab es mal ein Problem mit unterschiedlichen Connection-Strings. Aber das sollte imho mit der Fb2.5 sicher der Vergangenheit angehören. Wenn ich diese Ausführungen (mal nach 10054 suchen) zugrundelege, dann sieht es eher aus wie ein Hardware/Treiberproblem. Oder mit dem Routing unterwegs, schon mal mit fester IP-Adresse probiert, statt sich auf die Namensauflösung zu verlassen?

Ich habe bei uns eben mal auf unseren Server (Fb1.5) geschaut. Seit Mai 2010 nicht ein Eintrag in dieser Richtung im log zu finden. Und leider kenne ich auch keine Einstellung in der firebird.conf, welche den Server etwas geschwätziger für Euch gestalten würde.

[Meta777]

Danke für deine Antwort. Das merkwürdige an der Sache ist auch das kein client den Hostnamen zum verbinden verwendet. Es sind überall nur die IP-Adressen verwendet worden. Ich hab auch auf dem Server selbst nochmal geschaut. Keines der dort laufenden softwaremodule hat DB-relavante Dinge getan die zu den Zeiten im Firebird-log passen. Sehr seltsam...

[hoika]

Hallo,

du könntest den Timeout hochsetzen,
der steht (?) bei 60 Sekunden.
FB schickt ja immer "Stay-Alive"-Pakete zu den verbundenen Clients.


Heiko

[DelphiBandit]

OK, Ihr arbeitet schon mit IP, dann ist es nicht diese Baustelle. Eine andere Möglichkeit, welche mir beim Durchlesen von Heiko's Antwort bzgl. des Timeout so in den Kopf kommt. Melden sich die Clients denn vernünftig bei der Datenbank ab? Oder wird die Anwendung schlagartig beendet ohne ein sauberes Disconnect durchzuführen. Dann laufen die beim Server natürlich zwangsläufig irgendwann als verlustig auf. Dabei reagieren wir in unserer Anwendung sowohl auf FormClose des Hauptformulars, welches ein vernünftiges Beenden bedeutet, als auch auf die Windows-Nachricht zum Herunterfahren "procedure TdlgHauptForm.WMQueryEndSession(var Msg: TWMQueryEndSession);". Weil viele Anwender abends einfach den Rechner runterfahren ohne die Anwendung vorher zu beenden - logisch, mach ich auch nicht anders :) Einzig ein Abwürgen des Tasks im Taskmanager bekommt man leider irgendwie nicht mit.

Du findest jede Menge, hoffentlich hilfreiche, Einträge über google "read errno = 10054" dazu. Vielleicht könnt Ihr mit den Zeiten dem Problem auf die Spur kommen - welcher der Clients war um die Uhr aktiv und hat was gemacht?!

[Meta777]

Hallo,
Danke für die Antworten. Ich denke der 10054 selbst ist nicht mal das Problem, scheint aber vielleicht ein tragischeres Problem mit dem "Classic Server" zu verursachen. Bei ca. 50 "fb_inet_server.exe" Instanzen lies der FB einfach keine weitere Connections von irgendeinen client - selbst local - zu. Im Log stand auch nichts weiter. Der Admin hat den Rechner dann einfach immer neugestartet. Wir haben jetzt den "Super Server" laufen und bisher läuft es. Es würde mich schon interessieren warum der FB als "Classic" einfach nicht mehr reagiert aber da es keine Testumgebung kann ich da auch nichts weiter machen. :x Gibt es da vielleicht ein Maximum an gleichzeitgien Verbindungen?

Falls noch jemand eine idee hat... immer her damit ^^

Shalom

[tsteinmaurer]

Solltest du Linux als Betriebssystem verwenden, dann kann man in einem Linux Config-File (ich denke, das von xinetd) einstellen, was die max. Anzahl an Verbindungen ist. Vielleicht kommst du ja durch das an dieses Limit heran.

[DelphiBandit]

Das wäre eine Möglichkeit. Ich vermute aber eher, dass er durch "unsauberes" Abmelden der Clients, bzw. ggf. gar nicht Abmelden, offene Zombie Tasks im Classic Server herumgeistern hat. Die Erkennung von verlorenen Connections soll beim 2.5 zwar wesentlich zuverlässiger sein, aber wer weiß. Habt Ihr 50 Arbeitsplätze, welche mit der Datenbank gleichzeitig arbeiten?

Übrigens wäre die SuperClassic Variante für Euch bestimmt noch eine Option, weil sie eine ideale Kombination aus beiden Welten ist. Der SuperServer hat imho den Nachteil, dass er bei stressigen Abfragen für alle merklich in die Knie geht.