Interbase 6: IBServer.exe gibt RAM nicht frei

[squetk]

Hallo,

bevor entsprechende Hinweise kommen: ja, wir haben selbstverständlich vor, in Kürze auf eine aktuelle Firebird-Version umzusteigen...

Unser Programm ist bei mehreren Kunden seit mehreren Jahren im Einsatz. Bei einem Kunden gibt es das Phänomen, dass der Speicherbedarf der IBServer.exe (Superserver-Installation, ca. 25 Connections, DB ist ca. 2.5 GB gross) auf dem Server (Windows 2003 2 GB RAM) im Tagesverlauf exorbitant in die Höhe schnellt. Das kann mitunter bis zu 2 GB betragen. Leider verabschiedet sich der IBServer dann mit der Fehlermeldung "..invalid save point...", was bedeutet, dass der Speicher zu knapp ist.
Wenn sich alle Clients am Abend abmelden, wird der belegte Speicher (im Taskmanager des Servers zu erkennen), nicht an das Betriebssystem zurückgegeben.
Erst wenn der Interbase-Server gestoppt und wieder gestartet wird, ist der Speicher wieder frei.

Ausser unserer Anwendung greifen noch Fremdanwendungen per ODBC auf die Datenbank zu (was bei den anderen Kunden nicht der Fall ist).

Meine erste Frage ist: Gibt es eine Möglichkeit, dieses Verhalten per Monitoring zu ermitteln, um dem auslösenden Programm auf die Schliche zu kommen?

Ebenfalls von Interesse ist, wie man Interbase zum Speicherfresser machen kann. Langlaufende Transaktionen (wie nach Google-Suche zu diesem Thema gelesen) können es eigentlich nicht sein, da tagsüber eher viele kurze Transaktionen stattfinden.

[hoika]

Hallo,

> Ausser unserer Anwendung greifen noch Fremdanwendungen per ODBC auf die Datenbank zu (was bei den >
> anderen Kunden nicht der Fall ist).>

Nun, wie kannst du ausschliessen, die die nicht lang laufende Transaktionen erzeugen ?

Sage dem Kunden doch mal, er soll die anderen Apps mal alle schliessen
und dann dem Ram-Verbrauch messen.

Ein Tool, was ich kenne ist der FBScanner (ibphoenix.com),
es gibt auch eine Testversion davon.

Das andere wäre der ibmonitor.

Heiko

[squetk]

Ich habe mal eine lang laufende Transaktion getestet - selbst wenn sie über Stunden läuft und innerhalb dieser mehr als 150000 SQL-Abfragen stellt, steigt der Speicherbedarf des IBServers kaum oder nur minimal.

FBScanner: schaut ganz gut aus, werde ich mal probieren.

Man kann - wenn alle Programme geschlossen werden - keine Freigabe des Speichers durch IBServer.exe erkennen.

Die Anzahl der bestehenden Connections ist normal - ich erwähne dies, weil ähnliche Probleme auftreten, wenn sehr viele Datenbankconnections geöffnet und nicht geschlossen werden.

[hoika]

Hallo,

das Problem ist nicht die langlaufende Transaktion selber,
sondern die anderen Transaktionen.

Transe_Lang
StartTransaction
Update ohne Commit


Transe_kurz 1
StartTransaction
Transaktionsmaske enthält auch Transe_Lang


Transe_kurz 2
StartTransaction
Transaktionsmaske enthält auch Transe_kurz1 und 2


IB muss immer mehr Speicher anfordern bei jeder neuen Transaktion


Heiko

[luka]

Steige doch so schnell wie nur irgend möglich auf Firebird um.

So lange könnte man einfach versuchen den Firebird Server zu benutzen.
Der sollte doch mit InterBase-Datenbanken klar kommen.

Gruß luka

[squetk]

Zitat von luka:

Steige doch so schnell wie nur irgend möglich auf Firebird um.

Danke luka, auf diesen Tipp habe ich gewartet..

Aber noch ist ja nicht sicher, ob mich das Szenario mit Firebird nicht ebenso heimsuchen kann.

Ich müsste diesen Interbase-Speicherhunger auch im Test hinkriegen können, so dass ich 1.) die Ursache ermitteln kann und 2.) prüfen kann, ob mir - wenn es keine andere Lösung gäbe - Firebird da weiterhelfen könnte.

Dazu werde ich mal ein Testprogramm stricken, das - wie hoika schrieb - eine lang laufende Transaktion mit parallelen kurzen Transaktionen simuliert.

[hoika]

Hallo,

was ich vergessen habe,

die lange Transaktion und die anderen müssen
verschiedene Connections (z.B. Rechner) sein.


Heiko