> Any hints how to investigate this problem?

>  Reproducible test case would be ideal
>

I spent three days now to reproduce this with non-production system  -  no success so far.

I am in contact with Alexey Kovyazin who got a minidump from production system, but I don’t know if he found a hot path till now.

I did a VMMap dump for him too, which shows a memory usage where at the beginning there some blocks with different sizes, i.e. one block which could be approx. page_buffers*page_size, so the db cache. Then there are many many small blocks of 64K this is which causes the mem consumption in my opinion. However, don’t understand very much how FB allocates mem internally.

When I open the string view in VMMap, I see that these 64K blocks contain many times the same set of table names: LAST_MODIFICATION, WB_PRG, EVENT_DATA, EVENT_HEADER and NONE – which is not a table name, perhaps the character set name, because I use NONE as charset. I checked some 64K blocks, and they contain all the same pool of strings.

The application accessing the db holds some permanently open connections with prepared statements performing actions regularly. But there are some actions which are triggered by clients of my application in regular intervals, which open and close the db connection each time. These regular things access the tables whose names I found in the 64K blocks. Together with NONE (perhaps send to the db when performing a new connect), maybe FB is leaking here on each connect / disconnect, not cleaning up correctly when a connection is closed? Interestingly, the string view never shows strings of the data which is contained in the tables.

These are some observations – I do not know if they are helpful at all.

---

Joja