On this page:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
16 rates
AppDynamics gathers Garbage Collection metrics and lets you analyze how periodic garbage collections affect the performance of your application. It is important to identify the impact of excessive garbage collection or memory-caused instability on the application. A typical JAVA application which runs on the Java Virtual Machine (JVM) creates objects such as strings, files, and arrays of primitives on the heap. The JAVA Garbage collection is an automatic memory management process which finds and gets rid of the objects which are no longer used by the application. The JVM periodically performs Garbage Collection to maximize available memory and the programmer need not explicitly mark the objects to be deleted. Garbage collection requires a stop-the-world suspension of all application threads. This process affects the performance, especially for applications with large amounts of data, multiple threads, and high transaction rates.

See How to Master Your Java Memory for a review of how generational garbage collection works. 

Before You Begin

If your application runs under JDK version 1.6.0_26-b03 and you have configured the monitored application to use G1GC, the Java Agent cannot capture memory statistics. To capture memory statistics, you can do any one of the following:

  • Remove G1GC (-XX:+UseG1GC) from the application startup options, or
  • Upgrade the JDK to version 1.6.0_32 or higher.

In JVM version 1.7 or later, the agent attaches listeners to the Java event notification service to generate garbage collection metrics. In JVM versions prior to 1.7, the agent parses certain JVM log files to generate metrics, so you must verify that your JVM is generating the required logs. See 'Enable Log-based Garbage Collection.'

Monitor Garbage Collection

The Java Agent reports certain garbage collection metrics at one-minute intervals. You can view these metrics on the Heap & Garbage Collection sub-tab of the Memory tab on the Node dashboard:

  • Heap utilization: free, used, committed, and available.
    This is the most coarse-grained view of memory use.
  • Garbage collection: minor, major, and total on one timeline.
    This should give you some notion of the ratio of minor to major collections.
  • Minor garbage collection on a timeline.
  • Major garbage collection on a timeline.
  • Memory pool use, including the use of all memory spaces: Young Generation, Old Generation, and PermGen.

For a finer-grained view of the impact of garbage collection on application performance, you can view garbage collection metrics in the Metric Browser. Navigate to Application Infrastructure Performance > tier > JVM > Garbage Collection.

In addition to the periodically-collected metrics, the Metric Browser shows the following metrics triggered by minor or major garbage collection events:

MetricTriggering EventDescription

Allocated-Objects

Minor collection

The amount of memory allocated to the Young Generation.

A high growth rate might indicate memory thrash. The allocation rate affects the frequency of minor collection events, which can impact application performance over time.

The value for Count indicates how many collections were made.

Promoted-ObjectsMajor collection

The amount of memory in use for objects promoted from Young Gen space to Old Gen space.

A high promotion rate is related to major collection events, which can have a significant impact on application performance due to the duration of a full major collection cycle.

If the promotion rate is close to the allocation rate, this might indicate premature promotion. In this case, you might want to allocate more memory to Young Gen space.

The value for Count indicates how many collections were made.

Freed Objects

Minor or Major collection

The amount of memory in use for objects being reclaimed in Young and Old space.

In a normal system, the number of objects allocated and the free rate metrics should be roughly equal.

The value for Count indicates how many collections were made.

LiveDataMajor collection

The amount of memory in use that persists after major garbage collections.

An upward slope in the size of live data indicates a possible memory leak.

 

Tune Garbage Collection in the JVM

After reviewing Garbage Collection diagnostic metrics, you can use the following JVM arguments to tune space allocation in the JVM garbage collection memory pool. For example, you might want to increase the size of tenured space if your application needs to store many objects long term.

OptionMeaning

-Xms

The amount of total memory allocated to young and old generation space.

-XX:NewSize

The amount of memory allocated to the young generation space.

-XX:PermSize

The amount of memory allocated to the permanent generation

Consult the documentation for your JVM for additional arguments that relate to Garbage Collection space allocation.

Enable Log-based Garbage Collection 

For applications running in JVMs prior to version 1.7, garbage collection monitoring is based on periodically parsing certain garbage collection logs. 

To set up garbage collection logging for your application, use the following arguments: 

-Xloggc:log-file-path 
-XX:+Usecollector-type 
-XX:+PrintGCDetails

The log-file-path option specifies where the log file is located. The table below describes the possible values for collector types for the -XX:+Usecollector-type option:

Collector TypeEffect

CMS Collector

-XX:+UseConcMarkSweepGC

Good for applications that require low pause times and that can share resources with the garbage collector.

Use the -XX:ParallelCMSThreads=<n> to set the number of threads to use.

Throughput or Parallel Collector

-XX:+UseParallelGC
-XX:+UseParallelOldGC

 Can use multiple CPUs to speed up application throughput; good to use for work-intensive apps that can accept long pauses.

G1 Collector

 -XX:+UseG1GC

Available in Java 7 and designed to be a long term replacement for the CMS collector. This is a parallel, concurrent, and incrementally compacting low-pause collector.


To direct the Controller to display logged information, register the following node properties in the Controller UI:

enable-jmx-visibility=true
enable-log-based-gc=visiblity=true

To change the default log check interval, register the following node property:

logbased-visibility-log-check-interval-in-mills=1000

Specify Regular Expressions for Parsing Garbage Collection Logs

When you enable log-based garbage collection metrics, the agent uses built-in regular expressions to accommodate different JDK and garbage collection type combinations. If the built-in regular expressions don't return the garbage collection metrics for your system, you can register the following node properties to specify custom regular expressions for parsing the logs:

  • young-gc-custom-regex-1
  • young-gc-custom-regex-2
  • young-gc-custom-regex-3
  • full-gc-custom-regex-1
  • full-gc-custom-regex-2
  • full-gc-custom-regex-3

After you set a custom regular expression using a node property, the agent no longer uses any of the built-in regular expressions to parse the logs.

 

  • No labels