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.