4 Coherenceでのデバッグ
この章の内容は次のとおりです。
- Coherenceでのデバッグの概要
一般的に、Coherenceアプリケーションは単一のコンピュータ上で開発されます。キャッシュ・サーバーおよびアプリケーションはIDE内で起動され、必要に応じてアプリケーションをデバッグします。 - ロギングの構成
Coherenceには独自のロギング・フレームワークがあり、一般的なアプリケーションのロギング環境を提供するLog4j2、Log4j、Slf4jおよびJavaロギングの使用もサポートされます。 - リモート・デバッグの実行
Java Debug Wire Protocol (JDWP)は、リモートでJVMをデバッグする機能を備えています。 - 分散トレース
Coherenceでは、OpenTracingAPIが使用されているので、開発者はクラスタ内でキャッシュ操作を可視化できます。 - Coherenceベース・アプリケーションのトラブルシューティング
Coherenceベース・アプリケーションのトラブルシューティングは、他のJavaアプリケーションのトラブルシューティングとほとんど変わりません。
親トピック: はじめに
Coherenceでのデバッグの概要
開発中にロギングを使用し、JVMデバッグ・オプションを有効にして、必要に応じてスレッドおよびヒープ・ダンプを取得することで、ほとんどのエラーを検出できることが理想的です。また、OracleのVisualVMやJConsoleなどのプロファイル・ツールおよびIDEは、問題を診断する機能を備えています。ただし、Coherenceアプリケーションは、最終的に分散環境でテストする必要があります。テスト環境でのデバッグおよびトラブルシューティングは、データおよびプロセスがクラスタ全体に完全に分散され、ネットワークがアプリケーションに影響するので、より困難になります。Java Debug Wire Protocol (JDWP)とCoherenceのJMX管理およびレポート機能を使用してリモート・デバッグを行うと、分散環境でのデバッグおよびトラブルシューティングが容易になります。
Oracleサポートの使用
My Oracle Supportがデバッグの問題に役立ちます。サポートに問題を送付する場合、必ず圧縮ファイルに次の項目を含めてください。
-
アプリケーション・コード
-
構成ファイル
-
すべてのクラスタ・メンバーのログ・ファイル
-
特定の環境では、スレッドおよびヒープ・ダンプが必要です。アプリケーションの実行が低速な場合やハングしそうな場合は、スレッド・ダンプを送信してください。アプリケーションでメモリー不足が発生する場合や、想定より多くのメモリーを消費する場合は、ヒープ・ダンプを送信してください。
親トピック: Coherenceでのデバッグ
ロギングの構成
この項には次のトピックが含まれます:
- ログ・レベルの変更
- ログ出力先の変更
- ファイルへのログ・メッセージの送信
- ログ・メッセージのフォーマットの変更
- ロギング文字制限の設定
- CoherenceログでのJDKロギングの使用
- JDKのログ・レベルとCoherenceのログ・レベルのマッピング
- CoherenceログでのLog4J 2ロギングの使用
- CoherenceログでのLog4J ロギングの使用
- Log4Jのログ・レベルとCoherenceのログ・レベルのマッピング
- CoherenceログでのSLF4Jの使用
親トピック: Coherenceでのデバッグ
ログ・レベルの変更
ロガーのログ・レベルにより、出力されるログ・メッセージを決定します。デフォルトのログ・レベルは、エラー、警告、情報、および一部のデバッグ・メッセージを出力します。開発時は、ログ・レベルを最大設定まで上げて、すべてのデバッグ・メッセージをログに記録するようにします。使用可能なログ・レベルは、次のとおりです。
-
0- このレベルには、ロギング・レベルに関連付けられていないメッセージが含まれます。 -
1- このレベルには、前のレベルのメッセージに加えて、エラー・メッセージも含まれます。 -
2- このレベルには、前のレベルのメッセージに加えて、警告メッセージも含まれます。 -
3- このレベルには、前のレベルのメッセージに加えて、情報メッセージも含まれます。 -
4-9- このレベルには、前のレベルのメッセージに加えて、内部デバッグ・メッセージも含まれます。ログ・レベルを上げると、より多くのログ・メッセージが出力されます。デフォルトのログ・レベルは5です。 -
-1- ログ・メッセージは出力されません。
ログ・レベルを変更するには、オペレーション・オーバーライド・ファイルを編集して、<severity-level>要素を<logging-config>要素の中に追加して、レベル番号を指定します。たとえば:
... <logging-config> ... <severity-level system-property="coherence.log.level">9 </severity-level> ... </logging-config> ...
オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.log.levelシステム・プロパティを使用してログ・レベルを指定できます。たとえば:
-Dcoherence.log.level=9
親トピック: ロギングの構成
ログ出力先の変更
ロガーは、複数の出力先にログ・メッセージを出力するように構成できます。コンソールへの標準出力に、stdoutとstderr (デフォルト)の両方を使用できます。ロガーは、指定されたファイルにメッセージを出力することもできます。
また、Coherenceでは、JDK、Log4j2、Log4jおよびSLF4Jの使用がサポートされており、アプリケーションとCoherenceで共通のロギング・フレームワークを共有できます。CoherenceログでのJDKロギングの使用、CoherenceログでのLog4J 2ロギングの使用、CoherenceログでのLog4Jロギングの使用およびCoherenceログでのSLF4Jの使用をそれぞれ参照してください。
ログ出力先を変更するには、オペレーション・オーバーライド・ファイルを編集して、<destination>要素を<logging-config>要素の中に追加して、出力先を指定します。たとえば:
... <logging-config> <destination system-property="coherence.log">stdout</destination> ... </logging-config> ...
オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.logシステム・プロパティを使用して、ログの出力先を指定できます。たとえば:
-Dcoherence.log=stdout
親トピック: ロギングの構成
ファイルへのログ・メッセージの送信
<destination>要素内にパスとファイル名を指定することで、ファイルにログ・メッセージを出力するようにロガーを構成できます。指定されたパスは、存在している必要があります。指定されたディレクトリにはアクセス可能で、書込み権限があることを確認してください。出力はファイルに追加され、サイズの制限はありません。プロセス間ではログ・ファイルを共有できません。プロセスが再起動するとログ・ファイルは置き換えられます。ファイルへのログ・メッセージの送信は、一般的には開発およびテスト時に行われ、特にログ・メッセージをOracleサポートに送信する必要がある場合に役立ちます。
次の例では、/tmpディレクトリに書き込まれるcoherence.logという名前のログ・ファイルを指定しています。
... <logging-config> <destination system-property="coherence.log">/tmp/coherence.log </destination> ... </logging-config> ...
親トピック: ロギングの構成
ログ・メッセージのフォーマットの変更
必要な詳細情報の量に応じて、デフォルトのログ・メッセージのフォーマットを変更できます。ログ・メッセージには、静的なテキストのほかに、実行時に置き換えられる次の任意のパラメータを含めることができます。
ノート:
ログ・メッセージのフォーマットを変更する場合は、注意深く行う必要があります。メンバーやスレッドなどの重要な情報が失われると、問題のデバッグが困難になる場合があります。
| パラメータ | 説明 |
|---|---|
|
|
このパラメータは、メッセージがログに記録された日付/時刻(ミリ秒まで)を示します。 |
|
|
このパラメータは、クラスタ・メンバーが稼働していた時間を示します。 |
|
|
このパラメータは、製品名とライセンス・タイプを示します。 |
|
|
このパラメータは、Coherenceのバージョンとビルドの詳細を示します。 |
|
|
このパラメータは、メッセージのロギング重大度レベルを示します。 |
|
|
このパラメータは、メッセージをログに記録したスレッド名を示します。 |
|
|
このパラメータは、クラスタ・メンバーIDを示します(クラスタが現在実行中の場合)。 |
|
|
このパラメータは、完全修飾クラスタ・メンバーID: cluster-name、site-name、rack-name、machine-name、process-nameおよびmember-name(クラスタが現在実行中の場合)を示します。 |
|
|
このパラメータは、クラスタ・メンバーの指定されたロールを示します。 |
|
|
このパラメータは、メッセージのテキストを示します。 |
|
|
このパラメータは、実行コンテキストID (ECID)を示します。ECIDは、Oracleコンポーネント間のリクエストにアタッチされるグローバルに一意のIDです。ECIDは、Oracle固有の診断機能であり、Oracleコンポーネントのログ・ファイルにわたってログ・メッセージを関連付けるために使用されます。また、複数のリクエストが並行して処理される場合に1つのコンポーネント内の同じリクエストに関するログ・メッセージを追跡するためにも使用されます。自身のログにECIDを含めるCoherenceクライアントは、Coherenceを起動するときに、アクティブなダイナミック・モニタリング・サービス(DMS)実行コンテキストを持っている必要があります。 ノート: JDKロギングをOracle Diagnostic Logging (ODL)ハンドラとともに使用する場合、ECIDは自動的にODLレコード・フォームの一部となるので、ODL |
ログ・メッセージのフォーマットを変更するには、オペレーション・オーバーライド・ファイルを編集して、<message-format>要素を<logging-config>要素の中に追加して、フォーマットを指定します。たとえば:
...
<logging-config>
...
<message-format>[{date}] <{level}> (thread={thread}) -->{text}
</message-format>
...
</logging-config>
...
親トピック: ロギングの構成
ロギング文字制限の設定
ロギング文字制限により、ロガー・デーモン・プロセスがメッセージ・キューから処理する最大文字数を指定します。この数を超過すると、キューに残っているメッセージがすべて破棄されます。廃棄されたメッセージはロギング・システムにより要約され、廃棄されたメッセージ数とその合計サイズの詳細が単一のログ・エントリに示されます。たとえば:
Asynchronous logging character limit exceeded; discarding 5 log messages (lines=14, chars=968)
切捨ては一時的なものにすぎません。キューが処理されると(空になると)ロガーはリセットされ、後続のメッセージがログに記録されるようになります。
ノート:
合計文字数が最大値を超えるメッセージが切り捨てられることはありません。
文字制限は、ロギングにより障害状態から回復できない状況を回避するために使用されます。たとえば、ロギングによりすでにタイトなタイミングが深刻化する場合があります。そうなると追加的に障害が発生し、さらに多くのロギングが生成されることになります。このサイクルは、回復不能になるまで続くことがあります。ロギングに制限をかけることで、このサイクルの発生を回避します。
ログの文字の制限を設定するには、オペレーション・オーバーライド・ファイルを編集して、<character-limit>要素を<logging-config>要素の中に追加します。文字制限は、0 (Integer.MAX_VALUE)または正の整数で入力します。たとえば:
... <logging-config> ... <character-limit system-property="coherence.log.limit">12288 </character-limit> </logging-config> ...
オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.log.limitシステム・プロパティを使用して、ログの文字制限を指定できます。たとえば:
-Dcoherence.log.limit=12288
親トピック: ロギングの構成
CoherenceログでのJDKロギングの使用
JDKロギング・フレームワークを使用するアプリケーションでは、CoherenceもJDKロギングを使用するように構成できます。JDKロギングの詳細は、このドキュメントでは述べません。JDKロギングの詳細は、http://download.oracle.com/javase/7/docs/technotes/guides/logging/overview.htmlを参照してください。
CoherenceログでJDKロギングを使用するには:
親トピック: ロギングの構成
JDKのログ・レベルとCoherenceのログ・レベルのマッピング
表4-1に、JDKのログ・レベルがどのようにCoherenceのログ・レベルにマッピングされるかを示します。
表4-1 JDKログ・レベルのマッピング
| JDKのログ・レベル | Coherenceのログ・レベル |
|---|---|
|
OFF |
NONE |
|
FINEST |
INTERNAL |
|
SEVERE |
ERROR |
|
WARNING |
WARNING |
|
INFO |
INFO |
|
FINE |
LEVEL_D4 |
|
FINER |
LEVEL_D5 |
|
FINEST |
LEVEL_D6 |
|
FINEST |
LEVEL_D7 |
|
FINEST |
LEVEL_D8 |
|
FINEST |
LEVEL_D9 |
|
ALL |
ALL |
親トピック: ロギングの構成
CoherenceログでのLog4J 2ロギングの使用
Log4j 2ロギング・フレームワークを使用するアプリケーションでは、CoherenceでもLog4j 2ロギングを使用するように構成できます。Log4j 2ロギングの詳細は、このドキュメントでは説明しません。Log4j 2ロギングの詳細は、http://logging.apache.org/log4j/2.x/manual/index.htmlを参照してください。
CoherenceログでLog4jロギングを使用するには:
親トピック: ロギングの構成
CoherenceログでのLog4Jロギングの使用
Log4jロギング・フレームワークを使用するアプリケーションでは、CoherenceでもLog4jロギングを使用するように構成できます。Log4jロギングの詳細は、このドキュメントでは説明しません。Log4jロギングの詳細は、http://logging.apache.org/log4j/1.2/manual.htmlを参照してください。
CoherenceログでLog4jロギングを使用するには:
親トピック: ロギングの構成
Log4Jのログ・レベルとCoherenceのログ・レベルのマッピング
表4-2に、Log4jのログ・レベルがどのようにCoherenceのログ・レベルにマッピングされるかを示します。
表4-2 Log4Jログ・レベルのマッピング
| Log4Jのログ・レベル | Coherenceのログ・レベル |
|---|---|
|
OFF |
NONE |
|
DEBUG |
INTERNAL |
|
ERROR |
ERROR |
|
WARN |
WARNING |
|
INFO |
INFO |
|
DEBUG |
LEVEL_D4 |
|
DEBUG |
LEVEL_D5 |
|
DEBUG |
LEVEL_D6 |
|
DEBUG |
LEVEL_D7 |
|
DEBUG |
LEVEL_D8 |
|
DEBUG |
LEVEL_D9 |
|
ALL |
ALL |
親トピック: ロギングの構成
CoherenceログでのSLF4Jの使用
SLF4Jロギングを使用するアプリケーションでは、CoherenceもSLF4Jロギングを使用するように構成できます。SLF4Jロギングの詳細は、このドキュメントでは述べません。SLF4Jロギングの詳細は、http://www.slf4j.org/を参照してください。
SLF4Jロギングを使用するには:
親トピック: ロギングの構成
リモート・デバッグの実行
キャッシュ・サーバーでリモート・デバッグを有効にするには、次のJVMオプションを使用してキャッシュ・サーバーを起動します。キャッシュ・サーバーを起動したら、IDEのデバッガを使用して、指定されたポート(この例では5005)でJVMに接続します。
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
アプリケーションが単一ノード・クラスタ上にない場合、クラスタのメンバー間でデータが分散されるため、Coherenceアプリケーションのリモート・デバッグは困難になる場合があります。たとえば、パラレル・グリッド操作を実行する場合、その操作は当該のデータが存在するクラスタ・メンバー上で実行されます。データが存在するのはどのメンバーか保証されていないので、最適な方法は単一のキャッシュ・サーバーを使用するようにテストを制約することです。
また、ガーディアンおよびパケット・タイムアウトを使用すると、クラスタのデバッグが困難になる場合があります。デバッガがパケットの公開、クラスタおよびサービス・スレッドを停止すると、クラスタ間で切断が発生する場合があります。そのようなシナリオでは、デバッグ・セッション中はガーディアンを無効にしてパケット・タイムアウトを増加します。service-guardianを参照してください。
親トピック: Coherenceでのデバッグ
分散トレース
OpenTracing APIが使用されているので、開発者はクラスタ内でキャッシュ操作を可視化できます。
Coherenceには、OpenTracing実装ライブラリは含まれません。したがって、開発者は必要なOpenTracingランタイムを提供する必要があります。「OpenTracing」を参照してください。ランタイムおよびOpenTracingの実装を検出するために、Coherenceでは、OpenTracingのTracerResolverを使用します。現在、JaegerはTracerResolverの実装を提供する唯一のOpenTracingフレームワークです。その他のOpenTracingフレームワークを使用することもできますが、開発者はTracerFactoryを実装し、OpenTracingフレームワークとともにCoherenceランタイム・クラスパスに提供する必要があります。
ノート:
必要に応じて、curlプロキシ・オプション(-xオプション)を使用して、プロキシ・サーバーの背後のインターネットにアクセスします。
curl -x <proxy-host>:<proxy-port>
<https://https://repo1.maven.org/maven2/io/jaegertracing/jaeger-client/<version-dir>/<pom.xml-file-name>たとえば、Jaegerを使用している場合、2つの(curlとmavenが使用可能な場合を想定)単純なコマンドで、必要な依存関係を取得できます。
# NOTE: Using version 1.0.0 as an example. Later versions would be acceptable. curl https://repo1.maven.org/maven2/io/jaegertracing/jaeger-client/1.0.0/jaeger-client-1.0.0.pom
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>io.jaegertracing</groupId>
<artifactId>jaeger-client</artifactId>
<version>1.0.0</version>
<name>jaeger-client</name>
<description>Jaeger Java bindings for OpenTracing API</description>
<url>https://github.com/jaegertracing/jaeger-client-java</url>
<licenses>
<license>
<name>The Apache License, Version 2.0</name>
<url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
</license>
<developers>
<developer>
<id>userid</id>
<name>user name</name>
<email>user email</email>
</developer
</developers>
<scm>
<connection>
scm:git:git@github.com:jaegertracing/jaeger-client-java.git
</connection>
<developerConnection>
scm:git:git@github.com:jaegertracing/jaeger-client-java.git
</developerConnection>
<url>
git@github.com:jaegertracing/jaeger-client-java.git
</url>
</scm>
<dependencies>
<dependency>
<groupId>io.jaegertracing</groupId>
<artifactId>jaeger-thrift</artifactId>
<version>1.0.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>io.jaegertracing</groupId>
<artifactId>jaeger-core</artifactId>
<version>1.0.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>io.jaegertracing</groupId>
<artifactId>jaeger-tracerresolver</artifactId>
<version>1.0.0</version>
<scope>compile</scope>
</dependency>
</dependencies>
</project>次のコードが続きます:
mvn dependency:copy-dependencies
このコマンドにより、必要なすべての依存関係がtarget/dependencyにコピーされます。依存関係が適切な場所に移動された後、新しい依存関係がクラスパスに含まれ、Jaegerを構成するためのすべての環境変数が指定されるように、Coherenceの起動に使用するスクリプトを更新します。
この項には次のトピックが含まれます:
トレースの構成
トレースを構成するには、オペレーション・オーバーライドtangosol-coherence-override.xmlファイルを編集し、子要素<sampling-ratio>を持つ<tracing-config>要素を追加します。
たとえば:
... <tracing-config> <sampling-ratio>0</sampling-ratio> <!-- user-initiated tracing --> </tracing-config> ...
トレースは3つのモードで動作します。
- -1 - この値はトレースを無効にします。
- 0 - この値はユーザーが開始するトレースを有効にします。これは、Coherenceが独自のトレースを開始するのではなく、アプリケーションが外部トレース・スパンを開始する必要があり、そこからCoherenceが内部トレース・スパンを収集することを意味します。外部トレース・スパンが開始されていない場合、トレース・アクティビティは実行されません。
- 0.01-1.0 - この範囲は、トレース・スパンが収集されていることを示します。たとえば、値が1.0の場合はすべてのスパンが収集され、値0.1の場合は10スパンごとに約1つが収集されます。
オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.tracing.ratioシステム・プロパティを使用して、トレース・サンプリング率を指定します。たとえば:
-Dcoherence.tracing.ratio=0
クラスタを起動する前に、jaeger-tracerresolverがJaegerバックエンドに接続するように正しく構成されていることを確認します。構成の詳細は、「jaeger-tracerresolver」を参照してください。
親トピック: 分散トレース
外部管理トレーサ
OpenTracingユーティリティに含まれるGlobalTracer APIを介してトレーサが使用可能であることを確認することで、Coherenceですでに作成されているトレーサを使用できます。この場合、Coherenceでは使用可能なトレーサが使用されますが、クラスタ・メンバーの終了時にトレーサの終了は試行されません。
親トピック: 分散トレース
Coherenceでのトレース操作
- パーティション・キャッシュの使用時に
NamedCacheAPIによって公開されるすべての操作。 - イベント・リスナーによって処理されるイベント(
EventInterceptorやMapListenerなど)。 - 永続性操作。
- CacheStore操作。
親トピック: 分散トレース
ユーザーが開始するトレース
サンプリング率を0 (ゼロ)に設定した場合は、Coherence操作を起動する前にトレース・スパンを開始する必要があります。
たとえば:
NamedCache cache = CacheFactory.getCache("some-cache");
Tracer tracer = GlobalTracer.get();
Span span = tracer.buildSpan("operation-name");
try (Scope scope = tracer.activateSpan(span))
{
cache.get("some-key");
}
finally
{
span.finish();
}ノート:
ユーザーが開始するトレースを有効にしても、アプリケーションがアクティブな外部トレース・スパンを開始しないかぎり、トレース・スパンは取得されません。親トピック: 分散トレース
Coherenceベース・アプリケーションのトラブルシューティング
単一のサーバー・クラスタ上でのCoherenceアプリケーションのトラブルシューティングは、一般的には単純になります。デバッグがしやすくなるため、ほとんどのCoherence開発作業はそのような環境で行われます。分散クラスタにデプロイされたアプリケーションのトラブルシューティングは、より困難になる場合があります。
この項には次のトピックが含まれます:
- Coherenceログの使用
- JMX管理およびCoherenceレポートの使用
- JVMオプションを使用したデバッグの促進
- 分散トレースの使用
- スレッド・ダンプの取得
- ヒープ・ダンプの取得
- オペレーティング・システムのモニタリング
親トピック: Coherenceでのデバッグ
Coherenceログの使用
ログ・メッセージは、Coherenceのモニターとトラブルシューティングに使用される情報を提供します。Oracle Coherenceの管理のログ・メッセージの用語集を参照してください。用語集には、追加の詳細情報およびメッセージが出力されたときに実行する処理が解説されています。
アプリケーションの開発およびデバッグ時に、デフォルトの初期状態の構成と異なるログの構成を行うことは非常に重要です。特に、最高のログ・レベル(JDKまたはlog4jロギングの使用時のレベル9またはALL)を使用すると、すべてのログ・メッセージが出力されるようになります。また、JDKまたはlog4jのロギングの使用も検討してください。両方のフレームワークとも、ファイル出力とコンソール出力の同時使用をサポートしています。最後に、すべてのログ・ファイルを共通のディレクトリに配置することを検討してください。共通ディレクトリを使用すると、ログ・ファイルの確認やCoherenceサポート・チーム宛のそれらのログ・ファイルのパッケージが容易になります。ロギングの構成を参照してください。
JMX管理およびCoherenceレポートの使用
Coherence管理は、Java Management Extensions (JMX)を使用して実装されます。Coherenceのヘルス状態および安定性の詳細を示す多くのMBeanが提供されます。MBeanは重要な分析情報を提供し、アプリケーションを開発環境から完全な分散環境に移行する際に使用する必要があります。MBeanには、JConsoleおよびVisualVMまたは、JMXをサポートする任意の管理ツールを使用してアクセスできます。またCoherenceには、MBeanから情報を長期的に収集するレポートが含まれ、単にMBeanをモニタリングするのみでは不可能な履歴情報を提供できます。レポートは、多くの場合、トラブルシューティングで重要となる傾向を特定するために使用されます。管理およびレポートは、デフォルトでは有効でないので、有効にする必要があります。Oracle Coherenceの管理のJMX管理の構成およびクラスタ・メンバーでのOracle Coherenceのレポート機能の有効化を参照してください。
JVMオプションを使用したデバッグの促進
ほとんどのJVMには、デバッグおよびトラブルシューティングを補助するためのオプションが含まれます。これらのオプションを使用して、情報を最大限に取得します。使用可能なオプションは、JVMベンダーのドキュメントを参照してください。このセクションで説明するJVMオプションは、Java HotSpot固有のものです。Java HotSpot VMオプションWebページを参照してください。
次のJVMオプション(標準および非標準)は、アプリケーションのデバッグおよびトラブルシューティング時に役立ちます。
-
-verbose:gcまたは-Xloggc:file- これらのオプションは、それぞれのガベージ・コレクション・イベントの追加ログを有効にするために使用されます。分散システムでは、単一のJVM上でGCが停止すると、多数のJVMのパフォーマンスに影響する場合があります。そのため、ガベージ・コレクションを注意深くモニターすることが重要になります。-Xloggcオプションは冗長GCと似ていますが、タイムスタンプが含まれます。 -
-Xprofおよび-Xrunhprof- これらのオプションは、JVMプロファイル・データを表示するために使用されます。本番システムでの使用を目的としたものではありません。 -
-XX:-PrintGC、-XX:-PrintGCDetailsおよび-XX:-PrintGCTimeStamps- これらのオプションも、ガベージ・コレクション時にメッセージを出力するために使用されます。 -
-XX:-HeapDumpOnOutOfMemoryErrorおよび-XX:HeapDumpPath=./java_pid<pid>.hprof- これらのオプションは、java.lang.OutOfMemoryErrorがスローされたときにヒープ・ダンプを初期化するために使用されます。 -
-XX:ErrorFile=./hs_err_pid<pid>.log- このオプションを使用すると、エラー・データがファイルに保存されます。
分散トレースの使用
分散トレースを使用すると、開発者はアプリケーションのプロファイリングおよび監視を行うことができます。これは、Coherenceなどのクラスタ環境で特に便利です。「分散トレース」を参照してください。
スレッド・ダンプの取得
スレッド・ダンプは、JVM内の各スレッドの詳細情報(スレッド状態など)を確認するために使用されます。スレッド・ダンプには、デッドロックした各スレッドの情報も含まれます(適用可能な場合)。Coherenceはマルチスレッド・アーキテクチャおよび分散アーキテクチャが採用されているため、スレッド・ダンプは有用です。スレッド・ダンプは、多くの場合、動作の遅いアプリケーションやデッドロックしたアプリケーションのトラブルシューティングに使用されます。スレッド・ダンプは単なるスナップショットにすぎないので、長時間で複数のダンプを収集するようにしてください。サポートの問題を送信する場合は、必ずスレッド・ダンプのセットを含めてください。
Coherenceは、ClusterMBean MBeanにあるネイティブlogClusterState JMX操作およびClusterNodeMBean MBeanにあるネイティブlogNodeState JMX操作を提供します。これらの操作によって、それぞれ、複数のクラスタ・メンバーまたは1つのクラスタ・メンバーに対するスレッド・ダンプ(未処理のポーリングを含む)が開始されます。Oracle Coherenceの管理のClusterMBeanおよびClusterNodeMBeanを参照してください。
UnixまたはLinuxオペレーティング・システム上でローカルにスレッド・ダンプを実行するには、アプリケーション・コンソールで[Ctrl]+[\]キーを押します。Windows上でスレッド・ダンプを実行するには、[Ctrl]+[Break](または[Pause])キーを押します。両方の方法とも、スレッド・ダンプとヒープ・サマリーが含まれます。
ほとんどのIDEは、IDEでの作業時にスレッド・ダンプを取得するために使用できるスレッド・ダンプ機能を備えています。また、UnixおよびLinuxオペレーティング・システムでは、kill -3 pidを使用して、IDEでリモート・スレッド・ダンプを発生させることができます。Windowsの場合、SendSignalなどのサード・パーティ・ツールを使用して、[Ctrl]+[Break]のシグナルをリモートJavaプロセスに送信し、IDEでダンプを発生させます。
OracleのVisualVM (visualvm)やJConsole (jconsole)などのプロファイル・ツールは、スレッド・ダンプを実行できます。これらのツールは、トラブルシューティングおよびデバッグ用の単一のツールを備えており、スレッドの詳細以外に様々な種類の情報を表示するので、非常に有用です。
最後に、jstackツールを使用して、任意のプロセスのスレッド・ダンプを取得できます。たとえば、jpsを使用してJavaプロセスIDを検索してから、コマンド行で次を実行します。
jstack <pid>jstackツールはサポートされていません。JDKの将来のバージョンで使用可能になるかどうかは未定です。
ノート:
デフォルトでは、CoherenceによってClusterMBean MBeanまたはサービス・ガーディアンを介して生成されるスレッド・ダンプには、ロックおよびデッドロック分析は含まれません。スレッド・ロックおよびデッドロック分析は、パフォーマンスに大きな影響を与える可能性があります。トラブルシューティングのために分析を含めるには、システム・プロパティcom.oracle.coherence.common.util.Threads.dumpLocksをtrueに設定します。
次のWLSTスクリプトを使用すると、WebLogicドメインでCoherenceを実行する際にクラスタ全体のスレッド・ダンプをトリガーできます:
# connect to domain runtime mbean server
connect(adminUser, adminPasswd, "t3://%s:%s" % (adminHost, adminPort))
domainRuntime()
# obtain coherece cluster mbean
cohClusterON=ObjectName("Coherence:type=Cluster,cluster=%s" % cohClusterName)
cohClusterMBean=list(mbs.queryMBeans(cohClusterON, None))
# obtain all mbean of coherence nodes associated with this cluster
cohClusterNodes=list(mbs.queryMBeans(ObjectName("Coherence:type=Node,cluster=%s,*" % cohClusterName), None))
# take a thread dump on each coherence member
types=["java.lang.String"]
for node in cohClusterNodes:
roleName=mbs.getAttribute(node.getObjectName(), "RoleName")
mbs.invoke(cohClusterMBean[0].getObjectName(), 'logClusterState', [roleName], types)ヒープ・ダンプの取得
ヒープ・ダンプは、JVMヒープ内のすべてのオブジェクトの詳細情報を確認するために使用されます。この情報には、ロードされたオブジェクトのインスタンス数およびオブジェクトに割り当てられたメモリー容量が含まれます。一般的にヒープ情報は、リソースの浪費またはパフォーマンスの低下の原因となっている可能性のあるアプリケーションの部分を見つけるために使用されます。Coherenceの完全な分散環境では、アプリケーションの処理がクラスタを横断して発生し、問題となるオブジェクトは必ずしもJVMにローカルであるとはかぎらないので、ヒープ・ダンプは扱いづらくなる場合があります。ヒープ・ダンプは単なる一時のスナップショットにすぎないので、長時間で複数のダンプを収集するようにしてください。サポートの問題を送信する場合は、必ずヒープ・ダンプを含めてください。
ヒープ・ダンプを最も簡単に取得するには、プロファイル・ツールを使用します。OracleのVisualVM (visualvm)およびJConsole (jconsole)は、ヒープ・ダンプ機能を備えています。また、ほとんどのIDEは、IDEでの作業時にヒープ・ダンプを取得するために使用できるスレッド・ダンプ機能を備えています。
代替案として、jmapツールを使用するとヒープ・ダンプを取得でき、jhatツールを使用するとヒープ・ダンプを表示できます。たとえば、jpsを使用してJavaプロセスIDを検索してから、コマンド行で次を実行します。
jmap -dump:format=b,file=/coherence.bin pid
ブラウザでヒープ・ダンプを表示するには、コマンド行で次を実行してから、返されたアドレスを参照します。ファイルは、VisualVMにロードして表示することもできます。
jhat /coherence.bin
jmapおよびjhatツールはサポートされていません。JDKの将来のバージョンで使用可能になるかどうかは未定です。
オペレーティング・システムのモニタリング
Coherenceベース・アプリケーションのトラブルシューティングおよびデバッグを行う際は、必ずクラスタ・メンバーのオペレーティング・システムをモニターします。オペレーティング・システムのチューニングが不十分な場合、クラスタ全体のパフォーマンスに影響することがあり、アプリケーションに悪影響がある場合があります。Oracle Coherenceの管理のオペレーティング・システムのチューニングを参照してください。
特に、次の領域をモニターすることは重要です。
-
CPU - プロセッサが長時間100%で稼働しているか?
-
メモリー/スワッピング - 使用可能なRAMメモリーを使い尽くし、スワップ・スペースの使用が発生しているか?
-
ネットワーク - バッファ・サイズ、ダイアグラム・サイズ、およびMaximum Transmission Unit (MTU)サイズが、パフォーマンスおよび成功率に影響しているか?
オペレーティング・システムの全体のヘルス状態をモニターするには、Unix/Linuxではvmstatおよびtop、WindowsではperfmonおよびWindows Sysinternalsから使用可能なツール(たとえば、procexpやprocmonなど)を使用します。Oracle Coherenceの管理のネットワーク・パフォーマンス・テストの実行を参照してください。