Did this article resolve your question/issue?


Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025



High cpu load for adminserver java process

« Go Back


Article Number000088351
EnvironmentProduct: OpenEdge Management
Version: 11.3 and later
OS: All supported platforms
Question/Problem Description
AdminServer java process shows a sustained high CPU load after the first poll interval
The OpenEdge Console is not available, trying to get to the site it sits on loading for ever when CPU spikes.
As more remote servers and managed resources are added, the java process uses up a lot of CPU time after the first poll interval

Steps to Reproduce
Clarifying Information
(embedded) orient databases have been re-created to upgrade them to the current version

All monitored OpenEdge databases are using the current VST's (updatevst)

Current Java heap is sufficiently sized (-Xmx2048m)
There are no java.lang.OutOfMemoryError issues

Memory size allocated for the database cache increased to roughly 10% of the cachedb size (fathom.init.params > storage.diskCache.bufferSize=512”)

Polling intervals have been tuned down from 5 to 15 minutes for resources that don't need high frequency polls
The sample time period the graph cache uses has been decreased from 15 to 8 days (Options > Graph Cache Database Configuration)

The fathom Compaction Job runs weekly
Error Message
Defect/Enhancement NumberDefect PSC00361693
When there are a lot of monitored databases, with many areas (particularly), performance of OEM takes a major hit.  The performance issue causes high CPU usage on the AdminServer java process due to expired graph cache records being deleted with an inefficient table scan.
Upgrade to OpenEdge 11.6.4, 11.7.3 Service Packs where the fix for this performance issue has been addressed by reworking the deleting of expired records.

Additionally, re-consider the suggestions in the Workaround Section below.
Review the Number of events configured for monitoring.
The more resources that are polled at a set interval the more memory is needed which leads to CPU spikes on the java process.

Revise and modify the Poll interval of monitored resources.
[Resource] > Monitoring Plans > Schedule Plan > EDIT : Advanced Settings
For example: Polling intervals can tuned down from 5 to 15 minutes for resources that don't need high frequency polls

Revise and re-configure the retention period for graph cache depending on the Resource:
Resources > Options > Graph Cache Database Configuration > Graph Cache Database Configure
For example: The sample time period the graph cache uses can decreased from 15 to 8 days 
Last Modified Date10/19/2018 11:11 AM