Can anyone point me to any steps we can use to troubleshoot high cpu in adminserver processes (ie. a java process on HP-UX running com.progress.chimera.adminserver.AdminServerStarter)?
After configuring OE Explorer and beginning to make use of remote(scripted) databases in the OE Explorer pages, the cpu on the server is being capped non-stop (ie. 2-3 cores are fully loaded).
I suspect that problems are related to malfunctioning database monitoring agents. The following can be found intermittently in admserv.log (after long intervals, sometimes > 30 secs):
[2017/04/18@09:39:03.896-0400]  [DatabaseAgent] VST query timed out after 30000 ms waiting for agent _SMDatabase_swtest query for table _UserTableStat. No data will be returned.[2017/04/18@09:40:42.081-0400]  [DatabaseAgent] VST query timed out after 30000 ms waiting for agent _SMDatabase_swtest query for table _UserIndexStat. No data will be returned.[2017/04/18@09:46:11.348-0400]  [DatabaseAgent] VST query timed out after 30000 ms waiting for agent _SMDatabase_swtest query for table _StorageObject. No data will be returned.[2017/04/18@09:46:14.077-0400]  [DatabaseAgent] VST query timed out after 30000 ms waiting for agent _SMDatabase_swtest query for table _UserIndexStat. No data will be returned.
I had no trouble with OE Explorer on a 64 bit Windows environment, although the configuration was slightly different, insofar as the explorer framework was managing my databases on the Windows server (via properties files) instead of monitoring the databases as "Scripted Databases".
If anyone has any experience with this stuff on HP-UX (IA64) please let me know. We were very hopeful that the OE Explorer would be more approachable and would give us another avenue for troubleshooting connectivity, performance and record-locking issues (without writing our own troublesome VST queries.) But by the looks of the VST errors being generated by the OE Explorer monitoring agent, it is not faring much better with these VST's.
At this time the problems I'm dealing with are in a testing environment that is almost totally "quiet" and inactive (aside from the CPU being hammered by adminserver monitoring agents).
Some years ago we tried to use the full OE management product on HP-UX and didn't have much luck with that at the time, eventually discontinuing our support because we weren't able to make it work. I'm assuming OE Explorer, being the free "built-in" management dashboard would work a bit better (whether on Windows or HP-UX).
Fixed for us in OE 11.7.4
Fixed for us in 11.7.4.
What version? There is an 11.6.0 bug that could trigger this when accessing user details page in OEE/OEM. Is fixed in later version.
I am having trouble replying to this forum post ( community.progress.com/.../194223 ) I'm trying to mark it closed. Was fixed for us by 11.7.4.
Was fixed in 11.7.4.
There is a hotfix for 11.7.4 to address a long standing high disk IO issue with OEM (doesn't affect OEE quite as much). It would have some CPU affect. I don't know of any run away resource usage other than that one in 11.7.4, but that particular bug has been there for a while. You can ask tech support for it. If that doesn't help, then we'd need jstack output to pursue anything.
Thanks Matt, I was out here in the forums today and decided it was time to close the loop on this old thread. That is the only reason you heard from me.
I tested OEE for OE 11.7.4 on both Windows and HPUX, and it works much more efficiently than before. Previously the user details page was unusable if table and index statistics were present. But things are better now.