Commented by: @hvlad

Send a link to me, please

Commented by: @hvlad

The problem is that one attachment works hard and not responds to the signals.
The hard work is garbage collection of index entries (IDX_garbage_collect).
What makes it so hard ? The length of backversions chain. It contains 419610 items !

I will improve engine responsiveness in this place but i doubt such database could work with approproate performance.

Commented by: Slavomir Skopalik (skopaliks)

Thanks for analysis! I will find who doing this.

Some related information for server improvement.
In past, I see similar problem on other customer and during clean up FB allocates really huge amount of RAM (>30GB).

In this case, server has only 10GB RAM and FB process takes ~12GB.
Can you check RAM allocation during this procedure?

Commented by: Slavomir Skopalik (skopaliks)

Vlad, one question, the 419610 items is for one record (max versions) or all records together (total versions)?

gstat for worst table at this moment:
Primary pointer page: 224, Index root page: 225
Average record length: 195.68, total records: 321882
Average version length: 18.97, total versions: 5764, max versions: 639
Data pages: 5171, data page slots: 5187, average fill: 84%

Commented by: @hvlad

Backversions chain i see in dump is for one record.
Record versions from this chain is cleaned up from disk at the moment.
This record versions exists in memory only to allow clean up unused index entries.

Commented by: @hvlad

As for the memory usage: the record length is 16 724 bytes, 16 724 * 419 610 = 7 017 557 640 or 6.5GB.
Attachment memory usage is 7 066 709 360 bytes, which is close to the value above.

Commented by: @hvlad

Fix is committed into v2.5.9

Commented by: @hvlad

Could you comment if it helps ?

Commented by: Slavomir Skopalik (skopaliks)

I will, however it is not easy to reproduce same situation.