Subscribe to Blog via Email
While enjoying the lovely Liverpool, UK weather at Tech14 with UKOUG, (just kidding about that weather part and apologies to the poor guy who asked me the origin of “Kevlar” which in my pained, sleep-deprived state I answered with a strange, long-winded response…. :)) a customer contacted me in regards to a challenge he was experiencing starting an agent on a host that was home to 100’s of targets.
oracle_database.DB301.com - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.rcvcat11 - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.DB302.com - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.B303.com - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.DB304.com - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.DB305.com - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.DB307.com - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.DB309.com - LOAD_TARGET_DYNAMIC running for 596 seconds oracle_database.B311.com - LOAD_TARGET_DYNAMIC running for 596 seconds Dynamic property executor tasks running ------------------------------ --------------------------------------------------------------- Agent is Running but Not Ready
The output from the “emctl start agent” wasn’t showing him anything he didn’t already know, but I asked him to send me the output and the following showed the actual issue that was causing the Agent not to finish out the run:
MaxThreads=96 agentJavaDefines=-Xmx345M -XX:MaxPermSize=96M SchedulerRandomSpreadMins=5 UploadMaxNumberXML=5000 UploadMaxMegaBytesXML=50.0 Auto tuning was successful ----- Tue Dec 9 12:50:04 2014::5216::Finished auto tuning the agent at time Tue Dec 9 12:50:04 2014 ----- ----- Tue Dec 9 12:50:04 2014::5216::Launching the JVM with following options: -Xmx345M -XX:MaxPermSize=96M -server -Djava.security.egd=file:///dev/./urandom -Dsun.lang.ClassLoader.allowArraySyntax=true -XX:+UseLinuxPosixThreadCPUClocks -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseCompressedOops ----- Agent is going down due to an OutOfMemoryError
This host target was a unique environment in that it contained so many targets, especially database targets. One of the reasons that the management agent was created and OEM processing removed from an internal database back-end process was to lighten the footprint. As EM12c introduced numerous features that has assisted its direction towards the center of the Oracle universe, the footprint became heavier, but I’ve been very impressed with development’s continued investment into lightening that footprint, even when considerable additions with plug-ins and metric extensions are added.
With all of this, the server administrator may have a different value set to limits on resource usage than what may be required for your unique environment. To verify this, I asked the customer to run the following for me:
ulimit -Su ulimit -Hu
Which returned the following expected values:
$ ulimit -Su 8192 $ ulimit -Hu 3100271
The user limit values with these added arguments are to locate the following information:
-H display hard resource limits.
-S display soft resource limits.
I asked him to please have the server administrator set both these values to unlimited with the chuser command and restart the agent.
The customer came back to confirm that the agent had now started, (promptly!) and added the remaining 86 database targets without issue.
The customer and his administrator were also insightful and correctly assumed that I’d made the unlimited values not indefinitely, but as a trouble-shooting step. The next step was to monitor the actual resource usage of the agent and then set the limits to values that would not only support the existing requirements, but allocate enough of a ceiling to support additional database consolidation, metric extensions, plug-in growth.