High cpu load for adminserver java process

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


 

(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

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.
Revise and modify the Poll interval of monitored resources.
Revise and re-configure the retention period for graph cache depending on the Resource:

Progress Articles:

How to manage the size of the FathomTrend Database   
 How to reclaim space used by the graph/activity database    

AdminServer slow to start on Linux   
 Cachedb is growing beyond the expected size