04 Aug 2015 08:37 PM - last edited on 04 Sep 2023 10:18 AM by MaciejNeumann
The most crucial information for optimizing the performance of a JVM is the allocation of memory heaps, knowing when the garbage collection activity suspends a process and how much memory was utilized during this cycle.
How can you see the real time JVM metrics for your application?
Dynatrace provides visibility into all the JVM metrics. This information is available for each Java process in the following way:
The memory pool sizes need to be configured for obtaining the optimum garbage collection behavior. In this blog post I will discuss the different memory pools how they affect the applications performance.
Eden Space: also known as Young Generation: This space contains all the newly created objects. Most of the objects get dereferenced or made unreachable soon after their creation.
Survivor space: The objects that were not dereferenced in the young generation will be copied to survivor space by the garbage collector.
Old Generation: The largest memory pool is for long living objects. The objects get copied to this space as they leave the survivor spaces.
Perm Gen: This pool keeps information about the applications classes. For most applications this space does not require any configuration.
Code Cache: The memory used for compilation and storage of native code.
The basic principle guiding these memory pools is that the Eden space should be large enough to hold all the temporary objects and the old gen space should hold all the permanent objects. The old gen space needs to be configured such that after a major GC at least 50% of the space remains free or the GC run times are too high.
Garbage collections are “Stop the World” events, as all the application threads are stopped until the operation completes. As the Eden space keeps short lived objects, minor GC is a fast process which does not affect the application whereas major GC takes significantly longer as it needs to check all the live objects. This operation needs to be minimized because it will render the application unresponsive for its duration. This unresponsiveness of the application is measured only by Dynatrace and shown as a value called Suspension, indicating for how much time was the application in suspended state due to the Major GC. This is an important variable to measure as increased GC activity causes a problem only when it is rending an application unresponsive.
Large number of Major GC’s eventually lead to time out errors for the application. These are diagnosed by Dynatrace and are shown up as Garbage Collection Problems on the dashboard. If there are no problems reported, you can navigate to the Java process and click on the area showing Suspension on the infographic and get all the information.
05 Aug 2015 06:32 AM
Even if GC suspension doesn't slow down your app it might consume a lot of resources. Dynatrace also shows you how much CPU the GC is using as can be seen here. Dynatrace now covers CPU consumption for all GCs, even CMS.
30 Nov 2023 05:22 PM
Thanks for the great information you shared but I have a question.
How are these details captured by Dynatrace? I'm looking to understand what is the process how JVM metrics are being monitored by dynatrace. Can you please share the details around it.
09 May 2024 04:17 AM
@alijamshed
OneAgent gets the memory values directly from the JVM via default API
https://docs.oracle.com/javase/8/docs/api/java/lang/management/MemoryMXBean.html