Firebird Server wurde unerwartet beendet.

[MarcoWarm]

Hallo zusammen,

wir haben seit geraumer Zeit Probleme mit der Stabilität unserer Firebird Server. Ich weiß es kann an allen Ecken hängen aber nun wissen wir uns leider keinen anderen Rat mehr und wollten nachfragen, ob wir noch etwas übersehen haben.

Symptom
Der Firebird Dienst wird beendet und, nach der in der Diensteverwaltung eingetragenen Zeit (60 sec), neu gestartet. Im System Log steht ein lapidares

Code:

Der Dienst "Firebird Server - DefaultInstance" wurde unerwartet beendet. Dies ist bereits 1 Mal vorgekommen. Folgende Korrekturmaßnahmen werden in 60000 Millisekunden durchgeführt: Neustart des Diensts.

Danach läuft der Server auch fröhlich weiter als wär nichts gewesen. Leider werden alle Verbindungen getrennt (ist ja auch klar). Unsere Anwendungen sind zwar schon auf diesen Fehler hin optimiert worden, aber wenn sich zu diesem Zeitpunkt jmd in ner Transaktion befindet ist das Schimpfen groß.
Das Firebird.log enthält keinen Hinweis. Weder auf einen Neustart einen Fehler in der Datenbank (page error etc.) gar kein Eintrag. Ja, es ist auch die korrekte Datei. Wenn ich den Dienst manuell beende und neu starte steht der Eintrag auch richtig im Log. Das Firebird trace log enthält auch nichts, wenn tracing mal aktiviert ist.


Umgebung
Wir nutzen zur Zeit

• 4 identische XEN (V 3.3.1) Server mit Windows Server 2008 R2 Enterprise. (8 CPU; 18 GB)
• Firebird 2.5.0 64bit Release. Super Classic Server (Das Problem war auch in allen RCs von FB 2.5)
  Datenbankgröße 25,5 Gb ... wachsend
  ca 50-60 Nutzer pro Datenbank.
• Die 4 Datenbanken werden miteinander und mit einem weiteren (der backward compatibility wegen) Interbase Server repliziert (der hingegen läuft stabil grml)
  Wegen der Replikation fallen pro Tag eine Menge Transaktionen und Schreibzugriffe an.
• UDFs von freeAdHocUDF

was wir schon versucht haben

• Forced Writes;Page Buffers = 90 bei PageSize = 4096 - jeder viel größere Wert der Buffers > 120 verschlimmert das Problem
• Es wird sichergestellt, daß sich verschiedene Scripte niemals gleichzeitig an der Datenbank anmelden. Das klingt verwirrend, aber wenn wir mit IBEScript 60 Verbindungen gleichzeitig öffnen und dann das gleiche Select durchführt, bekommen wir den Fehler provoziert. Und das umso zuverlässiger, je größer die Buffers sind. aber mit Buffers von 90 sollten doch 60 Verbindungen ein klacks sein, oder?
• scheinbar unzuverlässige UDFs wurden weggelassen
• sehr lange laufende (und viel lesende) Verbindungen (=Replikationsdienst) werden regelmäßig getrennt.
• es gibt keine lange laufenden Schreibtransatktionen (selten über 5 Minuten) Read-Only Transaktionen können unter Umständen lange >1h laufen (wegen lange laufender Reports und Auswertungen für den Chef ;-) )
• Alle Server haben die gleiche nahezu original config (siehe Anhang)

Und noch was?
Der Fehler tritt häufiger bei den Servern mit vermehrter Last auf. (d.h. viele Verbindungen, viele Schreibzugriffe). Aber das ist nicht vorhersagbar. Manchmal läuft der Server 3 Tage durch um dann von jetzt auf gleich neu zu starten. Manchmal hält der selbe Server keine 2 Stunden durch. Die Last ist jedoch jeden Tag ähnlich und die Scripte laufen nach Zeitplan. Der Zeitplan lässt auch keine Rückschlüsse auf den Absturz zu. Es lässt sich also kein Script als Schuldiger finden.
Ich habe noch keine offizielle Bug-Meldung dafür gefunden. Vielleicht hatte/hat jmd ein ähnliches Problem und weiß einen Rat.

Wir sind für jede Hilfe dankbar

Gruß
Marco

[tsteinmaurer]

Hallo,

wenn es keinen Hinweis im firebird.log gibt, dann wird es schwierig in irgendeine Richtung zu gehen. Welche Client-Bibliothek wird denn von den Clients verwendet? Einfach mal SysInternals ProcessExplorer anwerfen.

Hast ja sonst schon einiges versucht/geschrieben. UDFs sind immer ein "Indiz". Aber auch hier sollte etwas im firebird.log stehen.

Sonst würd ich mal den Kontakt mit dem Firebird-Dev-Team und den Einsatz eines Debug-Builds vorschlagen.

Thomas

[mkinzler]

Du könntest auch mit einem SQL-Monitor o.ä. die Staements loggen um zu sehen, ob es nicht doch an einem bestimmten Statement ( Funktion/UDF) liegt.

[MarcoWarm]

Danke erstmal für die Antworten.

Zitat:

Zitat von tsteinmaurer

Welche Client-Bibliothek wird denn von den Clients verwendet?

Die 32bit fbclient.dll der Version 2.5.0

Zitat:

Zitat von tsteinmaurer

Sonst würd ich mal den Kontakt mit dem Firebird-Dev-Team und den Einsatz eines Debug-Builds vorschlagen.

Das werd ich vermutlich tun müssen. Allerdings müssten wir dazu wohl einen extra Server aufsetzen, da ein DebugBuild in der Produktivumgebung wohl nicht besonders performant ist, oder?

Zitat:

Zitat von mkinzler

Du könntest auch mit einem SQL-Monitor o.ä. die Staements loggen.

Die Trace-Funktion von Firebird macht das ja schon. Die Abstürze sind aber in den Trace-Logs nicht mit irgendeiner Abfrage in Verbindung zu bringen. Und die Tracelogs sagen auch nicht, daß irgendwas schief gelaufen ist. Es wird einfach getraced und getraced ... und nach dem Absturz weiter getraced... so lässt sich auch im log nicht genau sagen wann der Absturz genau war. Es sei denn man macht eine längere Neustartzeit (5Minuten) damit man den Zeitsprung sieht. Aber da steigen uns die User aufs Dach, wenn die DB 5 minuten weg ist.

[tsteinmaurer]

Gut, dann haben wir das mit der Client-Library mal geklärt. Das passt so.

Bzgl. Debug-Build: Ja, das stimmt schon, schneller wirds nicht. Ich kann nicht sagen, um wieviel prozentuell es langsamer sein wird. Aber im Falle der Bearbeitung mit dem Dev-Team wirst du vermutlich nicht rundherum kommen.

Bzgl. Trace: Dann verwendest vermutlich ein System Audit durch Setzen des Parameters in firebird.conf? Wenn ja, dann ist es richtig, dass nach dem Neustart automatisch wieder mit dem Trace begonnen wird. Was du hier brauchst ist ein User Trace, das manuell von einem Benutzer angestoßen werden muss, damit was getraced wird. Unverschämte Werbung: Unser Firebird Trace Manager (http://www.upscene.com/go/?go=fbtm) kann dir hier weiterhelfen.

lg,
Thomas

[mkinzler]

Welche Zugriffskomponenten werden eingesetzt?

[MarcoWarm]

Zitat:

Zitat von mkinzler (Beitrag 1055273)

Welche Zugriffskomponenten werden eingesetzt?

• von der Delphi-Seite: FibPlus 6.9.9 2009/2010
• einige (5-6) Clients nutzen den Firebird ODBC client: Version 2.0 Release Candidate 1 (Abstürze gibt es aber auch auf den Servern, wo der ODBC Client nicht hinkommt)
• IBExpert 2010.06.20 (Abstürze sind auch nachts, wenn niemand über IBExpert auf die Datenbank schaut)
• IBEScript.dll (immer die gleiche wie die IBExpert Version)

Gruß
Marco

[MarcoWarm]

Zitat:

Zitat von tsteinmaurer (Beitrag 1055269)

Bzgl. Trace: Dann verwendest vermutlich ein System Audit durch Setzen des Parameters in firebird.conf? Wenn ja, dann ist es richtig, dass nach dem Neustart automatisch wieder mit dem Trace begonnen wird. Was du hier brauchst ist ein User Trace, das manuell von einem Benutzer angestoßen werden muss, damit was getraced wird. Unverschämte Werbung: Unser Firebird Trace Manager (http://www.upscene.com/go/?go=fbtm) kann dir hier weiterhelfen.

Jupp wir haben das System Audit verwendet. Was das usertrace angeht müssten wir 150-200 Connections tracen 24 Stunden am Tag... da kommt ne Menge Log zusammen ... und da den schuldigen zu finden ... ich schau mir euer Tool mal an. Danke :thumb:

Gruß
Marco

[tsteinmaurer]

Hallo,

ein System Audit unterscheidet sich von einem User Trace eigentlich nur dahingehend, dass halt das SystemAudit beim Firebird Server Start automatisch gestartet. Die möglichen Konfigurationsparameter sind eigentlich ident. D.h., auch mit einem System Audit kann ordentlich was zusammenkommen, wenn eine Fülle an unterschiedlichen Eventtypen mitgetraced werden. :-D

lg,
Thomas

[MarcoWarm]

da muss ich mich mal belesen

Gruß
marco