Autor Beitrag
dirksen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 23

Win 7, Win 8, Win 2012 Server R2
Delphi 7, Delphi XE2, VS 2008
BeitragVerfasst: Mi 08.06.16 12:39 
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.
Lemmy
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 789
Erhaltene Danke: 49

Windows 7 / 10; CentOS 7; LinuxMint
Delphi 7-XE10.1, VS 2015
BeitragVerfasst: Mi 08.06.16 19:06 
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)?
dirksen Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 23

Win 7, Win 8, Win 2012 Server R2
Delphi 7, Delphi XE2, VS 2008
BeitragVerfasst: Mi 08.06.16 22:03 
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.
Lemmy
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 789
Erhaltene Danke: 49

Windows 7 / 10; CentOS 7; LinuxMint
Delphi 7-XE10.1, VS 2015
BeitragVerfasst: Mi 08.06.16 22:17 
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?
jaenicke
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 18694
Erhaltene Danke: 1620

W10 x64 (Chrome, IE11)
Delphi 10.2 Ent, Oxygene, C# (VS 2015), JS/HTML, Java (NB), PHP, Lazarus
BeitragVerfasst: Do 09.06.16 06:28 
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.
dirksen Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 23

Win 7, Win 8, Win 2012 Server R2
Delphi 7, Delphi XE2, VS 2008
BeitragVerfasst: Do 09.06.16 09:01 
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?
dirksen Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 23

Win 7, Win 8, Win 2012 Server R2
Delphi 7, Delphi XE2, VS 2008
BeitragVerfasst: Do 09.06.16 09:57 
Die Speicherstatistik sieht so aus:

ausblenden Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
MON$STAT_ID   MON$STAT_GROUP   MON$MEMORY_USED   MON$MEMORY_ALLOCATED   MON$MAX_MEMORY_USED   MON$MAX_MEMORY_ALLOCATED
   1               0              69316216           321216512              69600160                321548288
   2               1              57556              0                      93252                   69632
   3               2              5144               0                      5208                    0
   4               2              12928              0                      25980                   0
   5               3              4752               0                      6472                    0
   6               3              14368              0                      19736                   0
   7               3              10120              0                      11416                   0
   8               1              9772               0                      95044                   69632
dirksen Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 23

Win 7, Win 8, Win 2012 Server R2
Delphi 7, Delphi XE2, VS 2008
BeitragVerfasst: Mo 13.06.16 16:23 
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.