Need help to analyse very high memory usage by objectdb (PRU, SEV, VAL[])

Hello,

we have a useCase in which we consume too much memory and run into a "GC overhead limit exceeded" exception.

Nearly 90% of the memory are taken by com.objectdb.o.PRU (49%) com.objectdb.o.SEV (29%) and com.objectdb.oVAL [] (9%).

When debugging, we did not get the reason for the high memory consumption yet.

Can you give us any any hints, which leads to the generation of these objects?

We assume that we (erroneously) refer to too many entities in the memory.

For example, we are not yet sure if the objects are created when executing queries, persisting new entities, or modifying them.  Any kind of hints would help us to analyse/fix our problem.

We use version 2.6.9_08 in embedded mode.

Small hint @ObjectDB (not related to this thread):

I got the following message after save this thread:

SMTP -> ERROR: RCPT not accepted from server: 554 5.7.1 Service unavailable; Helo command [www.objectdb.com] blocked using dbl.spamhaus.org; https://www.spamhaus.org/query/domain/objectdb.com
    SMTP -> ERROR: RCPT not accepted from server: 554 5.7.1 Service unavailable; Helo command [www.objectdb.com] blocked using dbl.spamhaus.org; https://www.spamhaus.org/query/domain/objectdb.com
    Forum Thread Need help to analyse very high memory usage by objectdb objects (PRU, SEV, VAL[]) has been created.

This may be caused by large insert / update transactions, with large amount of data pending to be written to the database on commit.

We have now completely changed the affected part, since the problem is gone.

For tests I had used a scenario in which the memory has just passed (3 GB). And then the database file size was just 10 MB. Can the memory consumption of over 2GB with ObjectDB Objects nevertheless be explained with generation or update of entities?

We had not created many entries and deleted them again. However, we can not exclude that existing objects have been modified over and over again.

When a persistent object is modified the entire object content becomes pending for writing to the database (until transaction commit), so with many updates or updates of large objects this is possible.