[
https://issues.redhat.com/browse/DROOLS-4645?page=com.atlassian.jira.plug...
]
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/...
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)