Arbeitsspeicherproblem bei SQL Abfragen

[kandalf]

So, also ich verstehe es einfach nicht. Vielleicht ist da ja doch ein Bug in der Firebird oder es gibt noch mehr Speicherangaben.

Habe nun die Datenbank mit Backup/Restore von 16384 auf 8192 Page Size konvertiert. Page Buffers ist jtzt nur noch 75.

Das Speicherproblem bleibt.
Ich mache ein paar Alter INDEX x ACTIVE auf Tabellen mit mehr als 2 Mio Datenstätze und schon sind 1-1.5 GB Arbeitsspeicher weg.

[kandalf]

So, nun noch mal die gleiche Datenbank mit Page Size 4096.
Nach ein paar SQL Befehlen sind schon wieder 1.1 GB Speicher reserviert.

Noch irgendjemand eine Idee dazu? Ich bin im Moment mit meinem Latein am Ende...

also die Verkleinerung von 16386 über 8192 nach 4096 hätte sich doch auswirken müssen oder?

[defo]

Ich hab wie gesagt keine Ahnung von den technischen Hintergründen bei Firebird, aber wieso soll eine konstante Datenmenge, die in kleinere Häppchen unterteilt wird, weniger Speicher verbrauchen? Angenommen es wäre ein Bug, würde nicht eine kleinere Stückelung eher zu noch mehr Problemen führen (Memory Leaks, ..)
Mir ist auch nicht klar, was daran so schlimm ist. Wenn der Speicher verfügbar ist und eine umfangreiche Aufgabe erledigt werden muss, warum soll dann nicht jede greifbare Resource verwendet werden. Und wenn sie verwendet wird, warum sollte Cache Speicher bspw gelöscht werden, bevor eine Verbindung getrennt wird? Soll der Cache sich denken, dass Du eh gleich zumachst und sich schon vorzeitig verabschieden.

[kandalf]

Also, ich komme derzeit echt nicht weiter.
Mit dem Program RamMap kann ich auch nichts entdecken.

Wenn es wirklich Filecache oder so was sein soll dann müßten doch die Änderungen mit den Page Sizes und den Page Buffers Auswirkungen gehabt haben oder?

[Thomas Steinmaurer]

Page Size and Page Buffers definieren den RAM-Verbrauch des Firebird Prozesses (SuperClassic, SuperServer) oder der Firebird Prozesse (Classic).

Der Filesystem-Cache obliegt dem Betriebssystem und hat nichts mit Firebird zu tun. Windows cacht einfach selbst auch (hast mal versucht eine > 1 GB Datei zwei mal zu kopieren, wenn du genügend RAM hast).

Im schließe mich "defo" an, dass ich mir keine weiteren Sorgen machen würde, sofern du nicht in Szenarien wie Swapping etc. kommst. Ist doch gut, wenn RAM ausgelastet ist. In der Regel beschweren sich die Leute, dass zuwenig RAM verwendet wird.

[kandalf]

Page Size and Page Buffers definieren den RAM-Verbrauch des Firebird Prozesses (SuperClassic, SuperServer) oder der Firebird Prozesse (Classic).

Der Filesystem-Cache obliegt dem Betriebssystem und hat nichts mit Firebird zu tun. Windows cacht einfach selbst auch (hast mal versucht eine > 1 GB Datei zwei mal zu kopieren, wenn du genügend RAM hast).

Im schließe mich "defo" an, dass ich mir keine weiteren Sorgen machen würde, sofern du nicht in Szenarien wie Swapping etc. kommst. Ist doch gut, wenn RAM ausgelastet ist. In der Regel beschweren sich die Leute, dass zuwenig RAM verwendet wird.

Im Grunde gebe ich dir ja recht, ABER, leider wird der Speicher nicht freiegeben! Das führt dann evtl. dazu, dass Prozesse die für irgendeine Aktion plötzlich mehr Speicher benötigen diesen evtl. nicht mehr allokieren können.

Wenn dieser Speicher vom System verwendet wird und nicht von der Firebird, warum wird er denn dann freiegeben, wenn alle Datenbankverbindungen geschlossen werden?

[Thomas Steinmaurer]

Im Grunde gebe ich dir ja recht, ABER, leider wird der Speicher nicht freiegeben! Das führt dann evtl. dazu, dass Prozesse die für irgendeine Aktion plötzlich mehr Speicher benötigen diesen evtl. nicht mehr allokieren können.

Ich würde da mal einen Test machen, ob Windows den RAM wirklich nicht mehr
freigibt, wenn er von anderen Prozessen benötigt wird. Hattest du das schon? Darum auch ganz am Anfang meine Frage bzgl. dem Betriebssystem, weil es unter Windows Server 2008 tatsächlich ein Problem gibt, wo der Filesystem-Cache den verfügbaren RAM auffrißt. Sollte in Windows Server 2008 R2 und Windows 7 behoben sein.

Wenn dieser Speicher vom System verwendet wird und nicht von der Firebird, warum wird er denn dann freiegeben, wenn alle Datenbankverbindungen geschlossen werden?

Weil Windows vermutlich die Firebird-Datenbankdatei oder halt Teile im Filesystem-Cache hält.

[kandalf]

Gut, dass könnte ich mal machen. Durch deinen Hinweis mit dem File System Cache bin ich noch auf was gestossen.
Also für 64bit kann man diesen Wert in der Inidatei ändern und es gibt im firebird Tracker einen Eintrag, dass Windows mit grossen Datenbanken den kompletten Speicher frißt und dann crasht. Könnte schon passen.

[Thomas Steinmaurer]

Ach ja, in Firebird 2.5 gäbe es auch die Möglichkeit den Filesystem-Cache etwas zu kontrollieren. Siehe FileSystemCacheSize und FileSystemCacheThreshold in firebird.conf. Somit könnte man unterbinden, dass eine Firebird-Datei doppelt, sowohl vom internen Firebird Page Cache als auch vom Filesystem-Cache gecached wird.

[kandalf]

Habe noch einen Hinweis gefunden was damit zu tun haben könnte.
Ich nutze Firebird als 32 Bit Applikation, mein Prozess ist ebenfalls 32bit.
Angeblich soll es mit der 32bit Version unter dem 64bit Betriebssytem Probleme mit dem Speicher geben (FileSystemCache), dass er nicht freigegeben wird und auch zuviel nimmt.
Installiere nun mal die 64 Bit Firebirdvariante und werden meinen Prozess mal in 64bit compilieren.

Ergebnis:
Das war das Problem! Habe nun FileSystemCache auf 20 gesetzt, müsste also bei 4GB Arbeitstspeicher ca. 800 MB Cache sein. Und genau das ist der Wert der erreicht wird. Auch fällt der Wert nun zwischendurch immer mal wieder runter auf 200MB. Es scheint sich nun völlig anders zu verhalten.

Es hat also definitiv nur mit dem Filesystemcache zu tun. Vielen Dank für deinen Hinweis, das hätte ich so nie gefunden.

Windows7 64 Bit Systeme haben wir auch erst seit kurzem ein paar. Nun wird mir auch einiges klar.