1

We're using Appdynamics Java agent for monitoring our production applications. We have noticed slow growth in memory and the application eventually stalls. We ran a head dump on one of the JVMs and got the below reports.

Problem Suspect 1: The thread com.singularity.ee.agent.appagent.kernel.config.xml.a@ 0x1267...... AD thread config Poller keeps local variable config size of 28546.79(15.89%) KB

Problem Suspect 2: 280561 Instances of com.singularity.ee.agent.appagent.services.transactionmonitor.com.exitcall.p loaded by com.singularity.ee.agent.appagent.kernel.classloader.d@ 0x6c000.... occupy 503413.3(28.05%) KB. These instances are referenced from one instance of java.util.HashMap$Node[]...

We figured that these classes were from the Appdynamics APM that hooks on to the running JVM and sends monitored events to the controller. There is so much convoluted process associated with reaching out to the vendor, so I am wondering if there are any work arounds for this like we enabling our java apps with JMX and Appd getting the monitoring events from JMX rather than directly hooking on to the applications' JVM. Thanks for your suggestions.

MAYBEMEDIC
  • 49
  • 5
  • As for Problem Suspect2, it looks that exitcalls are not completing. You might try disabling the default implementation and code your own transaction/exitcall/etc. markers https://sdkdocs.appdynamics.com/javadocs/java-agent-api/v4.5/com/appdynamics/agent/api/Transaction.html#startExitCall-java.util.Map-java.lang.String-java.lang.String-boolean- with timeout completion – gliptak Jan 05 '21 at 16:24
  • Publishing as JMX metrics might be a workaround. Maybe review documentation at https://docs.appdynamics.com/display/PRO45/Configure+JMX+Metrics+from+MBeans – gliptak Jan 05 '21 at 16:26
  • What Java Agent version are you using? What is the instrumented application? What metrics do you actually need? – Ingmar Boddington Jan 06 '21 at 16:20

0 Answers0