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

[tsteinmaurer]

Wenn es rein um die neuen Tracing-Fähigkeitne geht und wenn du dem Englischen mächtig bist, dann kannst du dir meinen Artikel reinziehen: http://www.ibphoenix.com/main.nfs?a=...ce_steinmaurer

Sonst hätt ich auch noch eine deutsche Fassung aus dem Entwickler Magazin.


lg,
Thomas

[MarcoWarm]

Zitat:

Zitat von tsteinmaurer (Beitrag 1055295)

Sonst hätt ich auch noch eine deutsche Fassung aus dem Entwickler Magazin.

Danke ... Englisch ist kein Problem :-)

Gruß
Marco

[MarcoWarm]

Zitat:

Zitat von tsteinmaurer (Beitrag 1055210)

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

[MarcoWarm]

Zitat:

Zitat von IBExpert (Beitrag 1055447)

Bei der FreeadhocUDF kann ich dir (leider) im 2009 Stand einige Bugs nennen, die den
Server kommentarlos zum Absturz bringen.

Na bravo. Also F_STRCOPY nutzen wir nicht. Aber verschiedene andere Funktionen schon. da müsste ich jetzt mal alle (z.Zt. 956) Stored Procs durchschaun. Plus die verschiedenen Anwendungen. Das dauert ne Weile. Und den Verzicht zu predigen .... grml .... das wird dann wohl die schwerste Überzeugungsarbeit.
IBExpert hatte dochmal versprochen eigene UDFs rauszubringen ;-) Ist das noch auf der "roadmap"?

Zitat:

Zitat von IBExpert (Beitrag 1055447)

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.

Das mit dem restart werden wir wohl ändern. Datasets verwenden wir in der Regel nicht.
Danke erstmal für die neuen Anregungen. Ich werde mir mal die prozeduren, skripte und ibeblocks vornehmen... zumindest hab ich dann den Rest des Monats keine anderen Pflichten *lach*

Gruß
Marco

[IBExpert]

Zitat:

Zitat von MarcoWarm (Beitrag 1055486)

Na bravo. Also F_STRCOPY nutzen wir nicht. Aber verschiedene andere Funktionen schon. da müsste ich jetzt mal alle (z.Zt. 956) Stored Procs durchschaun. Plus die verschiedenen Anwendungen. Das dauert ne Weile. Und den Verzicht zu predigen .... grml .... das wird dann wohl die schwerste Überzeugungsarbeit.
IBExpert hatte dochmal versprochen eigene UDFs rauszubringen ;-) Ist das noch auf der "roadmap"?

Ich hoffe das wir auf der Firebird Konferenz eine erste Version schon mal publishen können, die wird dann auf Lazarus basieren. Aufgrund der sehr vielen eingebauten Funktionen in Firebird >=2.X brauch man viele Sachen aber gar nicht mehr aus einer UDF. Welche Prozeduren du benutzt siehst du wahlweise im Dependencies Viewer in IBExpert, oder mit dem sql unten am ende dieser nachricht.

Die UDFs dann in den Stored Procs zu ersetzen ist aber vergleichsweise simpel mit ibexpert. Einfach mit tools-extract metadata die prozeduren extrahieren, Das script enthält dann alle Prozeduren mit CREATE OR ALTER im Header. Auf dieser Script Datei kannst du dann ggf im Script executive per Suchen-Ersetzen einfach alle "F_...(" durch "xxx(" ersetzen, sofern
die jeweilige F_... Funktion ein eingebautes Äquivalent hat, ist aber bei vielen Funktionen gegeben. Danach dkannst du das Script einfach im Script executive laufen lassen, weil ja nicht gedropt werden muss. Alle Prozeduren werden dann mit alter wieder eingespielt und ersetzen die alten Versionen.


hier zum Beispiel die Abhängigkeiten für F_ABS

SQL-Code:

select
distinct
D1.RDB$DEPENDENT_NAME,
D1.RDB$DEPENDED_ON_NAME
from RDB$DEPENDENCIES D1
left join rdb$relations r1 on ((D1.RDB$DEPENDENT_NAME = r1.rdb$relation_name) and (not (r1.Rdb$View_Blr is null)))
where (D1.RDB$DEPENDED_ON_TYPE = 15)
and (D1.RDB$DEPENDENT_TYPE <> 3)
and (D1.RDB$DEPENDED_ON_NAME = 'F_ABS')
union
select
distinct
f2.rdb$relation_name,
D2.RDB$DEPENDED_ON_NAME
from rdb$dependencies d2, rdb$relation_fields f2
left join rdb$relations r2 on ((f2.rdb$relation_name = r2.rdb$relation_name) and (not (r2.Rdb$View_Blr is null)))
where (d2.rdb$dependent_type = 3) and
(d2.rdb$dependent_name = f2.rdb$field_source)
and (d2.rdb$depended_on_name = 'F_ABS')
order by 1, 2

[MarcoWarm]

Zitat:

Zitat von IBExpert (Beitrag 1055647)

Aufgrund der sehr vielen eingebauten Funktionen in Firebird >=2.X brauch man viele Sachen aber gar nicht mehr aus einer UDF.

Leider müssen wir organisationsbedingt (=das liegt nicht in meiner Hand) noch einen Interbase 2007 Server in der Replikation mitschleppen.

OT - ich weiß das ist absolut nicht nötig und die Umstellung auf FB (falls überhaupt erforderlich) dauert auch weniger als ne Woche ... aber was ich da schon geredet habe *kopfschüttel*

Das bedeutet natürlich auch, daß wir sämtliche Metadaten replizieren, damit wir die Stored Procs nicht doppelt pflegen müssen - damit sind dann auch Features wie CHAR_LENGTH() passe. Ich denke jetzt hab ich ein Argument den IB endlich abzuschalten *freu*, vielen Dank :thumb:.

Werden die IBExpert UDFs dann quelloffen sein?

Gruß
Marco

[IBExpert]

Zitat:

Zitat von MarcoWarm (Beitrag 1055684)

Werden die IBExpert UDFs dann quelloffen sein?

jo, das ist so vorgesehen