Enhancement #6233

DependencyChangesRequest holds a strong reference on to its parameter org.simantics.db.ChangeSet which can pile up in QueryProcessor and consume a lot of memory

Added by Tuukka Lehtonen about 2 years ago. Updated 10 months ago.

Status:On holdStart date:
Priority:4Due date:
Assignee:Antti Villberg% Done:

0%

Category:DB clientSpent time:-
Target version:-
Release notes:
Tags: perf, leak
Story points-
Velocity based estimate-

Description

Currently in an Apros stress test we have an undo test case where a script tries to perform the following operations on every diagram element in every model configuration diagram:
  1. transform the diagram element a bit
  2. undo

When this sequence is executed at full speed without any sleep, the DB client starts piling up DepdenciesRelation.DependencyChangeRequest instances in its query cache (readMap). The DependencyChangesRequest instances are shallowly not very large but the retained heap size is pretty much the amount of memory retained by class ClientChangesImpl, which is at least 128KB. In the mentioned test, the JVM ran into OOM, when it had around 22500 instances of DependencyChangesRequests cached resulting in a total retained heap of almost 3GB just because of these ClientChangesImpl instances.

Proposal:
  1. Make it possible to retrieve change set ID through ChangeSet interface
  2. Change the identity of DependencyChangesRequests from ChangeSet to ChangeSet ID
  3. Nullify ChangeSet parameter from DependencyChangesRequest after its execution

This will work because each DependencyChangesRequest for a certain change set will be cached for the time when each of GenericChangeListener is invoked that instantiates DependencyChangesRequest.

Of course this does not help with the fact that currently scripts can execute changes at such a rapid rate that the DB client caches will consume all JVM memory and the DB client query cache collector just does not have enough time to free up the necessary cache entries. However, this would be substantial reduction of used memory in cases where lots of requests are performed via script, which can happen also when executing model creation scripts etc.

History

#1 Updated by Tuukka Lehtonen over 1 year ago

  • Release changed from 31 to 39

#2 Updated by Tuukka Lehtonen about 1 year ago

  • Release deleted (39)

#3 Updated by Tuukka Lehtonen about 1 year ago

  • Tracker changed from Bug to Enhancement

#4 Updated by Tuukka Lehtonen about 1 year ago

  • Status changed from New to On hold

#5 Updated by Tuukka Lehtonen about 1 year ago

  • Tags changed from leak to leak, perf

#6 Updated by Tuukka Lehtonen 10 months ago

I'd recommend fixing this one way or another ASAP (preferable for 1.28.0 still). I believe that this would avoid some current cases of OOM and SCL-scripting high memory consumption problems.

Also available in: Atom PDF