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