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 von tsteinmaurer:

Welche Client-Bibliothek wird denn von den Clients verwendet?

Die 32bit fbclient.dll der Version 2.5.0

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 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 von tsteinmaurer:

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

Gruß
Marco

[MarcoWarm]

Zitat von tsteinmaurer:

den Einsatz eines Debug-Builds vorschlagen.

Nur die Frage, welcher Art die CrashDumps sein müssen. Ich hab (mangels DrWatson wie hier vorgeschlagen) das neue "Standardformat" WER (Windows Error Reporting) als Crash-Report bekommen. Ich hab nun keine Ahnung, ob das dem Dev-Team was nützt. Der Report enthält allerdings ein 150Mb Heapdump.

[tsteinmaurer]

Hallo,

hab dir eine persönliche Nachricht geschickt, dass wir das vielleicht Offline von dieser Liste abhandeln.

lg,
Thomas

[IBExpert]

Bei der FreeadhocUDF kann ich dir (leider) im 2009 Stand einige Bugs nennen, die den
Server kommentarlos zum Absturz bringen. Die sind auch schon gemeldet, aber trotzdem
nicht behoben. Das betraf in erster Linie die Stringverarbeitung, z.B. F_STRCOPY
Der Autor von der Freeadhocudf Lib hat mir im April 2009 bestätigt, den Fehler
gefunden zu haben und in der nächsten Version den beheben zu wollen. Blöderweise
gab es seit dem noch keine neue Version. Wenn du also irgendwo F_STRCOPY benutzt,
ersetze das durch F_MID, geht nahezu identisch, hat den Fehler aber nicht.

Ich verzichte überall wo es geht auf UDFs und da wo ich nicht wirklich drumherum komm,
mit Delphi nutze ich die eingebauten oder schreib ich die selber. Bei 32 Bit Windows war das
kein Problem, neuerdings aber lieber mit Lazarus, weil auch 64 Bit und andere Plattformen
verfügbar. Dazu zeige ich übrigens auch eine Session auf www.firebird-conference.com
in Bremen.

Ich würde übrigens das restart interval auf 0 sekunden setzen, warum soll der Dienst
60 Sekunden warten? und worauf? Je nach Aufbau eurer Software könnte man auf diesem
Wege auch über connection Probleme mit einem Autoreconnect transparent weiterarbeiten,
aber sobald datasets im Spiel sind wird das schwierig.

Kleine Korrektur: Es gab doch in 2009 noch eine neue Version, keine Ahnung ob da der
Fehler behoben war, weil ich seit April 2009 freiwillig die Freeadhoc nicht mehr
benutzt habe