[jboss-jira] [JBoss JIRA] (DROOLS-4645) High memory consumption with JIT

[Radovan Synek (Jira)]

    [ https://issues.redhat.com/browse/DROOLS-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13823440#comment-13823440 ] 

Radovan Synek commented on DROOLS-4645:
---------------------------------------

[~mfusco] acknowledged the issue, but requested further isolation, ideally to a drools level (removing optaplanner).

The suspected trigger for increased memory consumption is a huge move being generated (see the description). Thus, the isolation we might want to try is recording and replaying this move. If there is no way of registering a "move listener", it might require tweaking optaplanner to allow it.

After the move is available, the facts optaplanner starts with must be inserted via drools API to the kie session and the move rewritten as calls to drools API as well.

Another approach might be reusing a test generator ([~jlocker] can provide more information about this tool):
https://github.com/kiegroup/optaplanner/tree/master/optaplanner-core/src/main/java/org/optaplanner/core/impl/score/director/drools/testgen



> High memory consumption with JIT
> --------------------------------
>
>                 Key: DROOLS-4645
>                 URL: https://issues.redhat.com/browse/DROOLS-4645
>             Project: Drools
>          Issue Type: Bug
>          Components: executable model
>    Affects Versions: 7.29.0.Final
>            Reporter: Radovan Synek
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: Screenshot from 2019-10-15 10-30-27.png, Screenshot from 2019-10-15 10-31-53.png
>
>
> Employee Rostering example for OptaPlanner shows excessive memory consumption, which is connected with Drools score calculation.
> Please see the reproducer - running it without drools JIT finishes on time with 3GB of memory while with drools JIT being active it fails due to "GC overhead limit exceeded" despite the fact it god twice as much memory.
> Logging (add -Dlogback.level.org.optaplanner=trace to the execute_jit.sh script) showed there is a huge pillar move changing ~hundreds of entities which takes seconds to calculate score. During this move's evaluation, the memory consumption increases to a point when GC takes over and later fails. 
> Memory sampling and heap dump investigation showed there are ~10^7 objects of org.drools.core.reteoo.FromNodeLeftTuple class, taking more memory than any other data type in the VM.
> See the attached screenshots.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)