JMService Consumes an Enourmous Amount of Additional Memory During Normal Usage
Last updated on NOVEMBER 16, 2017
Applies to:Oracle Utilities Network Management System - Version 126.96.36.199 to 188.8.131.52 [Release 1.11 to 1.12]
Oracle Network Management for Utilities - DMS - Version 184.108.40.206 to 220.127.116.11 [Release 1.11 to 1.12]
Information in this document applies to any platform.
JMService consumes an ever increasing amount of memory.
Running 'Action any.JMService dump memstats' shows that JMJobManager is the culprit:
completedJobList.size() = 7075
job_by_alarm.size() = 7151
job_by_event.size() = 7151
jobs_by_device.size() = 76
jobs_by_sheet.size() = 0
calls_by_xid.size() = 137387
calls_by_intr.size() = 0
troubleFeeders.length() = 19
momentaryFeeder.getJobs().size() = 0
total # jobs by device = 76
total # jobs by sheet = 0
total # calls by xid = 2270526
total # calls by intersection = 0
total # jobs in troubleFeeders = 113
total distinct JMJob instances = 7158
total distinct JMCall instances = 2270598
bytes used by JMJob instances = 178922432
bytes used by JMCall instances = 5526416893
This can be reproduced (and is caused) by loading a large number of completed jobs using the "Load Completed Events - Range..." option in WorkAgenda and specifying a large date range.
Have the same or a different user repeat the "Load Completed Events - Range..." action specifying the same range. The number of JMCalls JMService has in memory will increase.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms