Hallo,
ich habe hier ein Projekt (32 Bit) in Delphi XE2 mit den UIB-Komponenten V2.5 und Firebird Server V2.5.2.26540 32 Bit (Superserver) das Messwerte bzw. Programme von verschiedenen Anlagen aufzeichnet und in der Datenbank speichert. Problem ist, nach ca. 3 - 4 Tagen ist der Speicherbedarf des Firebird bei ca. 4GB, er bekommt keinen Speicher mehr und es wird natürlich nichts mehr aufgezeichnet. Ich benutze für jede Abfrage ein eigenes von TUIBQuery abgeleitetes Objekt, das mir automatisch eine Transaktion (TUIBTransaction) erzeugt und diese für die Abfragen (Select, Insert, Update..) verwendet. Nach beenden einer Abfrage wird das Objekt freigegeben. Die verwendete Verbindung wird getrennt. Ich nutze zum Testen der Anwendung Windows 8.1 (64 Bit) bzw. Windows 2012 Server R2 (64 Bit). Bei beiden läuft der Speicher voll.
Ich habe schon mit den Caching Einstellungen im Firebird (FileSystemCacheThreshold, FileSystemCacheSize) gespielt, bzw. auch den 64 Bit Firebird Server verwendet. Im Trace and Audit mit Firebird ist mir auch nichts weiter aufgefallen (hängende Transaktionen). Was könnte das sein ?

Vielen Dank schon mal für Eure Hilfe.

Bitte nochmal zurück:

Wer bekommt keinen "Speicher" mehr? Anhand der 4 GByte wirst Du vermutlich den Hauptspeicher (RAM) meinen?

Und dann: steigt der Speicherbedarf von deinem Programm an, das Firebird nutzt, oder der Speicherbedarf des FIrebird-Dienstes?

Wenn es der Firebird-Dienst ist: Verwendest Du UDF (user defined functions)?

Der Firebird Dienst geht hoch bis kurz vor 4 GB (Arbeitssatz im Taskmanager) im firebird Log wird dann ein "Out Of Memory" Fehler ausgeloggt. UDF verwnde ich keine.

oha, das kenne ich so nicht. Ich habe die 2.5 aber noch nicht in Produktiveinsatz. Verwendest Du Blobs?
tracker.firebirdsql.org/browse/CORE-4671

Kannst Du mal die aktuellste 2.5er testen?

Bei der 64-Bit Variante läuft der Speicher dann weiter immer voller? Oder bekommst du da auch ein OutOfMemory und wenn ja, bei wie viel verwendetem Speicher?

Was ergibt die Speicherstatistik?
www.firebirdsql.org/...appx05-memusage.html
Darüber solltest du feststellen können wo der Speicher verwendet wird.

Für mich klingt das so als ob da Transaktionen geöffnet, aber nicht wieder freigegeben werden. Das sollte in der Speicherstatistik dann unter dem Typ Transaktionen auflaufen, wenn es so wäre.

Die aktuelle 2.5.5 habe ich auch schon probiert, gleiches Verhalten.

Die 64 Bit Version habe ich mal für ein paar Stunden am laufen gehabt, Speicher ist hier auch hoch gegangen, habe dann aber vorzeitig abgebrochen.
In Mon$Transactions habe ich keine offenen Transaktionen gefunden.

Ich habe mir das mal mit dem IBExpert Trace and Audit angeschaut, mir ist jetzt folgendes aufgefallen:

Bei Select Abfragen sieht das so aus:

Zitat:

- 2016-06-09T08:46:26.0600 (4528:00E7D7D0) START_TRANSACTION (TRA_1769990, CONCURRENCY | WAIT | READ_WRITE) - 2016-06-09T08:46:26.0610 (4528:00E7D7D0) PREPARE_STATEMENT (TRA_1769990, CONCURRENCY | WAIT | READ_WRITE) Statement 2484801: ------------------------------------------------------------------------------- Select MAX(ID) from .... - 2016-06-09T08:46:26.0620 (4528:00E7D7D0) EXECUTE_STATEMENT_START (TRA_1769990, CONCURRENCY | WAIT | READ_WRITE) Statement 2484801: - 2016-06-09T08:46:26.0620 (4528:00E7D7D0) CLOSE_CURSOR Statement 2484801: - 2016-06-09T08:46:26.0620 (4528:00E7D7D0) COMMIT_TRANSACTION (TRA_1769990, CONCURRENCY | WAIT | READ_WRITE) 0 ms, 1 write(s), 1 fetch(es), 1 mark(s) - 2016-06-09T08:46:26.0630 (4528:00E7D7D0) FREE_STATEMENT Statement 2484801:

Hier kommt nach dem COMMIT der Transaktion erst das FREE_STATEMENT, bei Insert Update läuft das genau anderst herum, erst FREE_STATEMENT und dann COMMIT.
Könnte es sein das hier von den Statements was hängen bleibt und nicht freigegeben wird?

Die Speicherstatistik sieht so aus:

Sieht so aus als ob das an den Statement Handles lag.
Ich benutze in meiner Software häufig "Insert into T_DATABASE (...) values (...) RETURNING ID". Diese SQL-Befehle werden von Firebird wie eine Stored procedure behandelt (Statement Type = stExecProcedure in UIB). Es wird Execute ausgeführt, aber zusätzlich ein SQL-Result zurückgegeben. In diesem Fall wurde zuerst COMMIT und dann FREE_STATEMENT beim Freigeben der Query durchgeführt. Jetzt hab ich eine kleine Änderung in UIB eingebaut damit in diesem Fall FREE_STATEMENT vor COMMIT durchgeführt wird. In einem ersten Test über 1 - 2 Stunden bleibt der Speicher des Firebird jetzt annähernd konstant und steigt nicht mehr.
Werde das ganze jetzt mal über ein paar Tage laufen lassen.