Versions Compared

    Key

    • This line was added.
    • This line was removed.
    • Formatting was changed.
    Comment: Published by Scroll Versions from this space and version 20.10
    Sv translation
    languageen

    This page covers how to monitor Garbage Collection for Java applications.

    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


    Anchor
    log-gc
    log-gc

    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: 

    No Format
    -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:

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

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

    No Format
    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.


    Sv translation
    languageja

    このページでは、Java アプリケーションのガベージコレクションをモニタする方法について説明します。

    AppDynamics では、ガベージ コレクション メトリックが収集され、定期的なガベージコレクションによってアプリケーションのパフォーマンスがどのような影響を受けるのかを分析できます。重要な点は、過剰なガベージコレクションやメモリが原因で不安定になることによるアプリケーションへの影響を特定することです。Java 仮想マシン(JVM)上で実行されている一般的な Java アプリケーションでは、プリミティブの文字列、ファイル、配列などのオブジェクトがヒープ上に作成されます。Java ガベージコレクションは、アプリケーションで使用されなくなったオブジェクトを見つけて削除する自動メモリ管理プロセスです。

    JVM では、使用可能なメモリ量を最大限にするためにガベージコレクションが定期的に実行されるため、プログラマはオブジェクトに削除対象のマークを明示的に付ける必要がありません。ガベージコレクションは、ストップザワールドによって、すべてのアプリケーションスレッドを一時停止する必要があります。このプロセスによって、特に大量のデータ、複数のスレッド、および高いトランザクション率を持つアプリケーションのパフォーマンスが影響を受けます。

    世代別ガベージコレクションの動作を確認するには、「Java メモリを習得する方法」を参照してください。 

    はじめに

    JDK バージョン 1.6.0_26-b03 でアプリケーションが実行され、G1GC を使用するようにモニタリング対象のアプリケーションが構成されている場合は、Java エージェントでメモリ統計をキャプチャできません。メモリ統計をキャプチャするには、次のいずれかを実行します。

    • アプリケーション起動オプションから G1GC(-XX:+UseG1GC)を削除します。または、
    • JDKをバージョン1.6.0_32以上にアップグレードします。

    JVM バージョン 1.7 以降では、ガベージ コレクション メトリックを生成するために、エージェントで Java イベント通知サービスにリスナーが追加されます。1.7 よりも前の JVM バージョンでは、メトリックを生成するために、エージェントで特定の JVM ログファイルが解析されます。そのため、JVM で必要なログが生成されていることを確認する必要があります。「ログベースのガベージコレクションの有効化」を参照してください。

    ガベージコレクションのモニタリング

    Java エージェントでは、特定のガベージ コレクション メトリックが 1 分間の間隔でレポートされます。これらのメトリックは、ノードダッシュボードのMemoryタブのHeap & Garbage Collectionサブタブに表示できます。

    • Heap utilization:空き、使用済み、コミット済み、利用可能。
      ここには、メモリの使用が最も大まかに表示されます。
    • Garbage collection:1 つのタイムラインのマイナー、メジャー、合計。
      これは、メジャーコレクションに対するマイナーコレクションの比率の概念を示している必要があります。
    • タイムラインのマイナー ガベージ コレクション。
    • タイムラインのメジャー ガベージ コレクション。
    • メモリプールの使用(すべてのメモリ領域:若い世代、古い世代、永続的な世代の使用を含む)。

    アプリケーションのパフォーマンスへのガベージコレクションの影響をより詳細に表示するために、メトリックブラウザでガベージ コレクション メトリックを表示できます。 Application Infrastructure Performance > tier > JVM > Garbage Collection に移動します。

    メトリックブラウザには、定期的に収集されたメトリックに加えて、マイナーまたはメジャー ガベージ コレクション イベントでトリガーされた次のメトリックも表示されます。

    メトリックトリガーイベント説明

    割り当てられたオブジェクト

    マイナーコレクション

    若い世代に割り当てられたメモリ

    高い増加率は、メモリスラッシングが発生していることを示している可能性があります。割り当て率はマイナーコレクションイベントの頻度に影響するため、長期間にわたってアプリケーションのパフォーマンスが影響を受ける可能性があります。

    [Count] の値は、作成されたコレクションの数を示します。

    格上げされたオブジェクトメジャーコレクション

    若い世代の領域から古い世代の領域に格上げされたオブジェクトで使用中のメモリ量

    高い格上げ率は、メジャーコレクションイベントに関連します。これによって、完全なメジャーコレクションサイクルの期間が原因でアプリケーションのパフォーマンスが大きな影響を受ける可能性があります。

    格上げ率が割り当て率に近い場合は、格上げが時期尚早であることを示している可能性があります。この場合、若い世代の領域により多くのメモリを割り当てることをお勧めします。

    [Count] の値は、作成されたコレクションの数を示します。

    解放されたオブジェクト

    マイナーまたはメジャーコレクション

    若い世代の領域と古い世代の領域で再利用されるオブジェクトで使用中のメモリ量。

    通常のシステムでは、オブジェクトの割り当て率と解放率メトリックの数をほぼ等しくする必要があります。

    [Count] の値は、作成されたコレクションの数を示します。

    LiveDataメジャーコレクション

    メジャー ガベージ コレクション後も存続する使用中のメモリ量。

    ライブデータサイズの上昇は、メモリリークが発生している可能性があることを示しています。


    JVMでのガベージコレクションの調整

    ガベージコレクションの診断メトリックを確認したら、次の JVM 引数を使用して、JVM ガベージコレクションのメモリプールで領域の割り当てを調整できます。たとえば、長期間に多数のオブジェクトがアプリケーションに格納される必要がある場合に、古い世代の領域のサイズを増加することがあります。

    オプション意味

    -Xms

    若い世代の領域と古い世代の領域に割り当てられた合計メモリ量。

    -XX:NewSize

    若い世代の領域に割り当てられたメモリ量。

    -XX:PermSize

    パーマネントジェネレーションに割り当てられたメモリ量。


    Anchor
    log-gc
    log-gc

    ログベースのガベージコレクションの有効化


    バージョン 1.7 よりも前の JVM で実行されているアプリケーションでは、特定のガベージコレクションログの定期的な解析に基づいてガベージコレクションがモニタリングされます。 

    アプリケーションのガベージコレクションログを設定するには、次の引数を使用します。

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

    log-file-path オプションでは、ログファイルを配置する場所が指定されます。以下の表では、-XX:+Usecollector-type オプションに指定できるコレクタタイプの値について説明します。

    コレクタタイプ効果

    CMSコレクタ

    -XX:+UseConcMarkSweepGC

    低停止時間が必須であり、リソースをガベージコレクタと共有できるアプリケーションに適しています。

    使用するスレッドの数を設定するには、-XX:ParallelCMSThreads=<n> を使用します。

    スループットまたはパラレルコレクタ

    -XX:+UseParallelGC
    -XX:+UseParallelOldGC

    複数の CPU を使用すると、アプリケーションのスループットを向上させることができます。長い停止時間を受け入れることができる作業集約型アプリでの使用に適しています。

    G1コレクタ

     -XX:+UseG1GC

    Java 7で使用でき、CMSコレクタの長期的な代替となるように設計されています。これは、並列的、同時的、増分的に小型化する低停止時間コレクタです。


    ログに記録された情報を表示するようにコントローラに指示するには、コントローラ UI で次のノードプロパティを登録します。

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

    デフォルトのログチェック間隔を変更するには、次のノードプロパティを登録します。

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

    ガベージコレクションログを解析する正規表現の指定

    ログベースのガベージ コレクション メトリックを有効にすると、エージェントでは、さまざまな JDK タイプとガベージコレクションタイプの組み合わせに対応するためにビルトイン正規表現が使用されます。ビルトイン正規表現からシステムのガベージ コレクション メトリックが返されない場合は、次のノードプロパティを登録してログを解析するカスタム正規表現を指定できます。

    • 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

    ノードプロパティを使用してカスタム正規表現を設定すると、ビルトイン正規表現のいずれかを使用してログを解析できなくなります。