Firebird 3 - Arbeitsspeicher Auslastung

[lxo]

Hallo,

ein Firebird-Server bei uns hat eine ungewöhnlich hohe Arbeitsspeicherauslastung.

Pagesize: 16.384
Pagebuffers: 10.000

Datenbankgröße: ca. 600MB
Aktive Verbindungen: 34
Älteste Verbindung ca. 2-3 Stunden alt, demnach auch die älteste Transaktion maximal so alt.


Die Arbeitsspeicherauslastung ist bei über 16GB?
Ist noch ok der Server hat 32GB zur Verfügung.
Es stört auch aktuell nicht aber es würde mich schon interessieren was das sein könnte.

Woran kann das liegen?
Jemand eine Idee?

[IBExpert]

hast du mal in MON$MEMORY_USAGE nachgesehen. ist zwar nicht immer selbsterklärend wie man das zuordnet aber dafür gibt es ibexpert

gründe können sein:
-irgendwelche änderungen an der firebird.conf
-viele ative statements mit non indexed reads, mit group by, order by non indexed, viel lange varchars in solchen result sets
-viele daten in GTT (global temporary table=memory tables)
-sehr komplexe metadaten (bei der averp datenbank braucht man ca 1gb ram pro connection, weil das ein metadatenmonster ist)
-viele statements in mon$statements prepared gelassen wegen programmierfehler (runtime instance tquery ohne close/free)
u.v.m.

ram speicher ist ja dafür da benutzt zu werden und nicht nur das servergehäuse zu beheizen und solange es nicht
dynmaisch schnell größer wird it das noch kein problem.

[lxo]

Zitat von IBExpert:

hast du mal in MON$MEMORY_USAGE nachgesehen. ist zwar nicht immer selbsterklärend wie man das zuordnet aber dafür gibt es ibexpert

gründe können sein:
-irgendwelche änderungen an der firebird.conf
-viele ative statements mit non indexed reads, mit group by, order by non indexed, viel lange varchars in solchen result sets
-viele daten in GTT (global temporary table=memory tables)
-sehr komplexe metadaten (bei der averp datenbank braucht man ca 1gb ram pro connection, weidas ein metadatenmonster ist)
-viele statements in mon$statements prepared gelassen wegen programmierfehler (runtime instance tquery ohne close/free)
u.v.m.

ram speicher ist ja dafür da benutzt zu werden und nicht nur das servergehäuse zu beheizen und solange es nicht
dynmaisch schnell größer wird it das noch kein problem.

Mit Hilfe in IBExpert dazu meinst du Database Monitoring und dann auf Statements?
Auch in der Auswertung wenn ich alles zusammenzähle komme ich 169MB und nicht 16GB.

Zitat:

-irgendwelche änderungen an der firebird.conf

- Seit 2019 nichts geändert

Zitat:

-viele ative statements mit non indexed reads, mit group by, order by non indexed, viel lange varchars in solchen result sets

- Im Schnitt ca. 10 Statements wenn ich auf "mon$statements" gehe. Ein Statement mit 54815 non_indixed_reads. Alle anderen 0 non_indixed_reads.

Zitat:

-viele daten in GTT (global temporary table=memory tables)

- Wie kann ich sehen ob irgendwas in den GTTs drin steht.
- Es gibt 7 solcher Tabellen mit "COMMIT PRESERVE ROWS". (Wenn ich mit einer anderen Connection reingucke sind ja aber leer)

Zitat:

-sehr komplexe metadaten (bei der averp datenbank braucht man ca 1gb ram pro connection, weidas ein metadatenmonster ist)

- Kein Unterschied zu anderen Datenbanken, dann sollte das auch wo anders auffallen.

Zitat:

-viele statements in mon$statements prepared gelassen wegen programmierfehler (runtime instance tquery ohne close/free)

- wie bereits erwähnt nur ca. 10 Statements im Schnitt.

[IBExpert]

was passiert denn nach db server restart? braucht der sofort so viel memory?
ansonsten mal trace api mitlaufen lassen, das könnte hinweise bringen
(falls das zu schnell das limit vom standard 10mb erriecht und deshalb stop
setzt das limit dafür in firebird.conf höher. ist da denn sonst noch alles
auf default? und gtt von anderer connection anschauen bringt nie ergebnisse,
das wusstest du aber ja schon.

ab fb5 gibt das noch mehr infos zum speicherverbrauch, das hilft dir bei fb3
aber nur begrenzt.

[dataspider]

Ich dachte zuerst an die Einstellung in der Firebird.conf:
ServerMode = Super

Aber da Super Standard ist, wird da sicher nicht Classic stehen?

Ansonsten gibt es noch einige Parameter wie:
TempBlockSize, TempCacheLimit, LockMemSize, LockHashSlots,
FileSystemCacheThreshold, DefaultDbCachePages, TcpRemoteBufferSize,
TempBlockSize, TempCacheLimit
die möglicherweise auf den Speicherverbrauch Einfluss haben.


Frank