| Oracle® Fusion Middleware Oracle Coherenceでのアプリケーションの開発 12c (12.1.3) E56206-04 |
|
 前 |
 次 |
この章では、ロギングを構成するための手順を説明し、Coherenceアプリケーションのデバッグおよびトラブルシューティングの際の一般的な注意点を示します。
この章には次の項が含まれます:
一般的に、Coherenceアプリケーションは1つのコンピュータ上で開発されます。キャッシュ・サーバーおよびアプリケーションはIDE内で起動され、必要に応じてアプリケーションをデバッグします。このような開発環境は、セットアップしやすく、最適に実行され、デバッグも容易です。ほとんどのアプリケーションは、この方法で作成およびテストできます。単一サーバーで実行するCoherenceの構成の詳細は、「単一サーバー・モードの有効化」を参照してください。
開発中にロギングを使用し、JVMデバッグ・オプションを有効にして、必要に応じてスレッドおよびヒープ・ダンプを取得することで、ほとんどのエラーを検出できることが理想的です。また、OracleのJava VisualVMやJConsoleなどのプロファイル・ツールおよびIDEは、問題を診断する機能を備えています。ただし、Coherenceアプリケーションは、最終的に分散環境でテストする必要があります。テスト環境でのデバッグおよびトラブルシューティングは、データおよびプロセスがクラスタ全体に完全に分散され、ネットワークがアプリケーションに影響するので、より困難になります。Java Debug Wire Protocol (JDWP)とCoherenceのJMX管理およびレポート機能を使用してリモート・デバッグを行うと、分散環境でのデバッグおよびトラブルシューティングが容易になります。
Oracleサポートの使用
Oracleサポートは、問題をデバッグする際に役立ち、https://support.oracle.comから利用できます。サポートに問題を送付する場合、必ず圧縮ファイルに次の項目を含めてください。
アプリケーション・コード
構成ファイル
すべてのクラスタ・メンバーのログ・ファイル
特定の環境では、スレッドおよびヒープ・ダンプが必要です。アプリケーションの実行が低速な場合やハングしそうな場合は、スレッド・ダンプを送信してください。アプリケーションでメモリー不足が発生する場合や、想定より多くのメモリーを消費する場合は、ヒープ・ダンプを送信してください。
Coherenceは、独自のロギング・フレームワークを持ち、一般的なアプリケーションのロギング環境を提供するlog4j、slf4jおよびJavaロギングの使用もサポートします。システムの重要な部分への影響を軽減するために、Coherenceでのロギングは優先度の低い専用のスレッドで実行されます。ロギングは事前構成されており、必要に応じてデフォルト設定を変更する必要があります。
この項には次のトピックが含まれます:
ロガーのログ・レベルにより、出力されるログ・メッセージを決定します。デフォルトのログ・レベルは、エラー、警告、情報、および一部のデバッグ・メッセージを出力します。開発時は、ログ・レベルを最大設定まで上げて、すべてのデバッグ・メッセージをログに記録するようにします。使用可能なログ・レベルは、次のとおりです。
0 - このレベルには、ロギング・レベルに関連付けられていないメッセージが含まれます。
1 - このレベルには、前のレベルのメッセージに加えて、エラー・メッセージも含まれます。
2 - このレベルには、前のレベルのメッセージに加えて、警告メッセージも含まれます。
3 - このレベルには、前のレベルのメッセージに加えて、情報メッセージも含まれます。
4-9 - このレベルには、前のレベルのメッセージに加えて、内部デバッグ・メッセージも含まれます。ログ・レベルを上げると、より多くのログ・メッセージが出力されます。デフォルトのログ・レベルは5です。
-1 - ログ・メッセージは出力されません。
ログ・レベルを変更するには、オペレーション・オーバーライド・ファイルを編集して、<severity-level>要素を<logging-config>要素の中に追加して、レベル番号を指定します。例:
... <logging-config> ... <severity-level system-property="tangosol.coherence.log.level">9 </severity-level> ... </logging-config> ...
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.log.levelシステム・プロパティを使用してログ・レベルを指定することもできます。例:
-Dtangosol.coherence.log.level=9
ロガーは、複数の出力先にログ・メッセージを出力するように構成できます。コンソールへの標準出力に、stdoutとstderr (デフォルト)の両方を使用できます。ロガーは、指定されたファイルにメッセージを出力することもできます。
また、Coherenceでは、JDK、log4jおよびSLF4Jの使用がサポートされており、アプリケーションとCoherenceで共通のロギング・フレームワークを共有できます。詳細は、「CoherenceログでのJDKロギングの使用」および「CoherenceログでのLog4Jロギングの使用」、「CoherenceログでのSLF4Jの使用」を参照してください。
ログ出力先を変更するには、オペレーション・オーバーライド・ファイルを編集して、<destination>要素を<logging-config>要素の中に追加して、出力先を指定します。例:
... <logging-config> <destination system-property="tangosol.coherence.log">stdout</destination> ... </logging-config> ...
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.logシステム・プロパティを使用して、ログの出力先を指定することもできます。例:
-Dtangosol.coherence.log=stdout
<destination>要素内にパスとファイル名を指定することで、ファイルにログ・メッセージを出力するようにロガーを構成できます。指定されたパスは、存在している必要があります。指定されたディレクトリにはアクセス可能で、書込み権限があることを確認してください。出力はファイルに追加され、サイズの制限はありません。プロセス間ではログ・ファイルを共有できません。プロセスが再起動するとログ・ファイルは置き換えられます。ファイルへのログ・メッセージの送信は、一般的には開発およびテスト時に行われ、特にログ・メッセージをOracleサポートに送信する必要がある場合に役立ちます。
次の例では、/tmpディレクトリに書き込まれるcoherence.logという名前のログ・ファイルを指定しています。
... <logging-config> <destination system-property="tangosol.coherence.log">/tmp/coherence.log </destination> ... </logging-config> ...
必要な詳細情報の量に応じて、デフォルトのログ・メッセージのフォーマットを変更できます。ログ・メッセージには、静的なテキストのほかに、実行時に置き換えられる次の任意のパラメータを含めることができます。
|
注意: ログ・メッセージのフォーマットを変更する場合は、注意深く行う必要があります。メンバーやスレッドなどの重要な情報が失われると、問題のデバッグが困難になる場合があります。 |
| パラメータ | 説明 |
|---|---|
{date} |
このパラメータは、メッセージがログに記録された日付/時刻(ミリ秒まで)を示します。 |
{uptime} |
このパラメータは、クラスタ・メンバーが稼働していた時間を示します。 |
{product} |
このパラメータは、製品名とライセンス・タイプを示します。 |
{version} |
このパラメータは、Coherenceのバージョンとビルドの詳細を示します。 |
{level} |
このパラメータは、メッセージのロギング重大度レベルを示します。 |
{thread} |
このパラメータは、メッセージをログに記録したスレッド名を示します。 |
{member} |
このパラメータは、クラスタ・メンバーIDを示します(クラスタが現在実行中の場合)。 |
{location} |
このパラメータは、完全修飾クラスタ・メンバーID: cluster-name、site-name、rack-name、machine-name、process-nameおよびmember-name(クラスタが現在実行中の場合)を示します。 |
{role} |
このパラメータは、クラスタ・メンバーの指定されたロールを示します。 |
{text} |
このパラメータは、メッセージのテキストを示します。 |
{ecid} |
このパラメータは、実行コンテキスト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="tangosol.coherence.log.limit">12288 </character-limit> </logging-config> ...
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.log.limitシステム・プロパティを使用して、ログの文字制限を指定するすることもできます。例:
-Dtangosol.coherence.log.limit=12288
JDKロギング・フレームワークを使用するアプリケーションでは、CoherenceもJDKロギングを使用するように構成できます。JDKロギングの詳細は、このドキュメントでは述べません。JDKロギングの詳細は、http://download.oracle.com/javase/7/docs/technotes/guides/logging/overview.htmlを参照してください。
CoherenceログでJDKロギングを使用するには、次の手順を実行します。
logging.propertiesファイルを作成します。次の例では、コンソールとファイルの両方にメッセージを出力するようにJDKロガーを構成します。コンソールおよびファイルへの出力は、FINESTログ・レベルを使用するように構成されています。ファイル・ハンドラ・パターンの場合、指定されたパスが存在している必要があります。また、指定されたディレクトリにはアクセス可能で、書込み権限があることを確認してください。
handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler .level=INFO Coherence.level=FINEST java.util.logging.FileHandler.pattern=/tmp/coherence%u.log java.util.logging.FileHandler.limit=50000 java.util.logging.FileHandler.count=1 java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
|
注意:
|
オペレーション・オーバーライド・ファイルの<destination>要素の値としてjdkを指定することで、JDKロギングを使用するようにCoherenceを構成します。例:
... <logging-config> <destination system-property="tangosol.coherence.log">jdk</destination> ... </logging-config> ...
logging.propertiesファイルが、java.util.logging.config.fileシステム・プロパティを使用して指定されていることを確認してください。例:
-Djava.util.logging.config.file=myfile
JDKのログ・レベルとCoherenceのログ・レベルのマッピング
次の表に、JDKのログ・レベルがどのようにCoherenceのログ・レベルにマッピングされるかを示します。
| 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 |
log4jロギング・フレームワークを使用するアプリケーションでは、Coherenceもlog4jロギングを使用するように構成できます。log4jロギングの詳細は、このドキュメントでは述べません。log4jロギングの詳細は、http://logging.apache.org/log4j/1.2/manual.htmlを参照してください。
Coherenceログでlog4jロギングを使用するには、次の手順を実行します。
log4j.propertiesファイルを作成します。次の例では、コンソールとファイルの両方にメッセージを出力するようにlog4jロガーを構成します。コンソールおよびファイルへの出力は、FATALログ・レベルを使用するように構成されています。ファイルに追加する場合、指定されたディレクトリにはアクセス可能で、書込み権限があることを確認してください。
log4j.logger.Coherence=FATAL, stdout, file log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%m%n log4j.appender.file=org.apache.log4j.RollingFileAppender log4j.appender.file.File=/tmp/coherence.log log4j.appender.file.MaxFileSize=10MB log4j.appender.file.layout=org.apache.log4j.PatternLayout log4j.appender.file.layout.ConversionPattern=%m%n
|
注意:
|
オペレーション・オーバーライド・ファイルの<destination>要素の値としてlog4jを指定することで、log4jロギングを使用するようにCoherenceを構成します。例:
... <logging-config> <destination system-property="tangosol.coherence.log">log4j</destination> ... </logging-config> ...
実行時にlog4j.jarファイルとlog4j.propertiesファイルの両方がクラスパスに存在するようにしてください。
Log4Jのログ・レベルとCoherenceのログ・レベルのマッピング
次の表に、log4jのログ・レベルがどのようにCoherenceのログ・レベルにマッピングされるかを示します。
| 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 |
SLF4Jロギングを使用するアプリケーションでは、CoherenceもSLF4Jロギングを使用するように構成できます。SLF4Jロギングの詳細は、このドキュメントでは述べません。SLF4Jロギングの詳細は、http://www.slf4j.org/を参照してください。
SLF4Jロギングを使用する手順は次のとおりです。
オペレーション・オーバーライド・ファイルの<destination>要素の値としてslf4jを指定します。例:
... <logging-config> <destination system-property="tangosol.coherence.log">slf4j</destination> ... </logging-config> ...
slf4j-api.jarファイルと、適切なロギング・フレームワークSLF4JバインディングJARが両方ともクラスパスにあることを確認します。
Java Debug Wire Protocol (JDWP)は、リモートでJVMをデバッグする機能を備えています。ほとんどのIDEツールは、JDWPをサポートし、リモート・デバッグを可能にするリモートJVMに接続するために使用されます。リモートJVMへの接続方法については、IDEのドキュメントを参照してください。
キャッシュ・サーバーでリモート・デバッグを有効にするには、次のJVMオプションを使用してキャッシュ・サーバーを起動します。キャッシュ・サーバーを起動したら、IDEのデバッガを使用して、指定されたポート(この例では5005)でJVMに接続します。
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
アプリケーションが単一ノード・クラスタ上にない場合、クラスタのメンバー間でデータが分散されるため、Coherenceアプリケーションのリモート・デバッグは困難になる場合があります。たとえば、パラレル・グリッド操作を実行する場合、その操作は当該のデータが存在するクラスタ・メンバー上で実行されます。データが存在するのはどのメンバーか保証されていないので、最適な方法は単一のキャッシュ・サーバーを使用するようにテストを制約することです。
また、ガーディアンおよびパケット・タイムアウトを使用すると、クラスタのデバッグが困難になる場合があります。デバッガがパケットの公開、クラスタおよびサービス・スレッドを停止すると、クラスタ間で切断が発生する場合があります。そのようなシナリオでは、デバッグ・セッション中はガーディアンを無効にしてパケット・タイムアウトを増加します。これらの設定の構成の詳細は、「service-guardian」を参照してください。
ここでは、一般的なトラブルシューティングの注意事項を示します。Coherenceベース・アプリケーションのトラブルシューティングは、他のJavaアプリケーションのトラブルシューティングとほとんどかわりません。ほとんどのIDEは、プロセスを補助する機能を備えています。また、Java VisualVM、JConsole、サード・パーティ・ツールなど多くのツールでは、Javaアプリケーションのモニターとトラブルシューティングを行うための容易な手段を提供しています。Javaのトラブルシューティングの詳細は、OTNのJava SEのトラブルシューティングのセクションを参照してください。
http://www.oracle.com/technetwork/java/javase/index-138283.html
単一のサーバー・クラスタ上でのCoherenceアプリケーションのトラブルシューティングは、一般的には単純になります。デバッグがしやすくなるため、ほとんどのCoherence開発作業はそのような環境で行われます。分散クラスタにデプロイされたアプリケーションのトラブルシューティングは、より困難になる場合があります。
この項には次のトピックが含まれます:
ログ・メッセージは、Coherenceのモニターとトラブルシューティングに使用される情報を提供します。ほとんどのログ・メッセージは、『Oracle Coherenceの管理』のログの用語集に関する項に説明があります。用語集には、追加の詳細情報およびメッセージが出力されたときに実行する処理が解説されています。
アプリケーションの開発およびデバッグ時に、デフォルトの初期状態の構成と異なるログの構成を行うことは非常に重要です。特に、最高のログ・レベル(JDKまたはlog4jロギングの使用時のレベル9またはALL)を使用すると、すべてのログ・メッセージが出力されるようになります。また、JDKまたはlog4jのロギングの使用も検討してください。両方のフレームワークとも、ファイル出力とコンソール出力の同時使用をサポートしています。最後に、すべてのログ・ファイルを共通のディレクトリに配置することを検討してください。共通ディレクトリを使用すると、ログ・ファイルの確認やCoherenceサポート・チーム宛のそれらのログ・ファイルのパッケージが容易になります。ロギングのすべての側面の構成の詳細は、「ロギングの構成」を参照してください。
Coherence管理は、Java Management Extensions (JMX)を使用して実装されます。Coherenceのヘルス状態および安定性の詳細を示す多くのMBeanが提供されます。MBeanは重要な分析情報を提供し、アプリケーションを開発環境から完全な分散環境に移行する際に使用する必要があります。MBeanには、JConsoleおよびVisualVMまたは、JMXをサポートする任意の管理ツールを使用してアクセスできます。またCoherenceには、MBeanから情報を長期的に収集するレポートが含まれ、単にMBeanをモニタリングするのみでは不可能な履歴情報を提供できます。レポートは、多くの場合、トラブルシューティングで重要となる傾向を特定するために使用されます。管理およびレポートは、デフォルトでは有効でないので、有効にする必要があります。Coherenceに備わる管理機能の使用方法の詳細は、『Oracle Coherenceのマネージメント』を参照してください。
ほとんどのJVMには、デバッグおよびトラブルシューティングを補助するためのオプションが含まれます。これらのオプションを使用して、情報を最大限に取得します。使用可能なオプションは、JVMベンダーのドキュメントを参照してください。このセクションで説明するJVMオプションは、Java HotSpot固有のものです。すべてのJVMオプションの詳細情報と使用方法は、Java HotSpot VMオプションのWebページを参照してください。
>http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html">>http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
>次の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 - このオプションを使用すると、エラー・データがファイルに保存されます。
スレッド・ダンプは、JVM内の各スレッドの詳細情報(スレッド状態など)を確認するために使用されます。スレッド・ダンプには、デッドロックした各スレッドの情報も含まれます(適用可能な場合)。Coherenceはマルチスレッド・アーキテクチャおよび分散アーキテクチャが採用されているため、スレッド・ダンプは有用です。スレッド・ダンプは、多くの場合、動作の遅いアプリケーションやデッドロックしたアプリケーションのトラブルシューティングに使用されます。スレッド・ダンプは単なるスナップショットにすぎないので、長時間で複数のダンプを収集するようにしてください。サポートの問題を送信する場合は、必ずスレッド・ダンプのセットを含めてください。
Coherenceは、ClusterMBean MBeanにあるネイティブlogClusterState JMX操作およびClusterNodeMBean MBeanにあるネイティブlogNodeState JMX操作を提供します。これらの操作によって、それぞれ、複数のクラスタ・メンバーまたは1つのクラスタ・メンバーに対するスレッド・ダンプ(未処理のポーリングを含む)が開始されます。Coherence MBeanの詳細なリファレンスは、『Oracle Coherenceのマネージメント』を参照してください。
UnixまたはLinuxオペレーティング・システム上でローカルにスレッド・ダンプを実行するには、アプリケーション・コンソールで[Ctrl]+[\]キーを押します。Windows上でスレッド・ダンプを実行するには、[Ctrl]+[Break](または[Pause])キーを押します。両方の方法とも、スレッド・ダンプとヒープ・サマリーが含まれます。
ほとんどのIDEは、IDEでの作業時にスレッド・ダンプを取得するために使用できるスレッド・ダンプ機能を備えています。また、UnixおよびLinuxオペレーティング・システムでは、kill -3 pidを使用して、IDEでリモート・スレッド・ダンプを発生させることができます。Windowsの場合、SendSignalなどのサード・パーティ・ツールを使用して、[Ctrl]+[Break]のシグナルをリモートJavaプロセスに送信し、IDEでダンプを発生させます。
OracleのJava VirtualVM (jvisualvm)やJConsole (jconsole)などのプロファイル・ツールは、スレッド・ダンプを実行できます。これらのツールは、トラブルシューティングおよびデバッグ用の単一のツールを備えており、スレッドの詳細以外に様々な種類の情報を表示するので、非常に有用です。
最後に、jstackツールを使用して、任意のプロセスのスレッド・ダンプを取得できます。たとえば、jpsを使用してJavaプロセスIDを検索してから、コマンド行で次を実行します。
jstack <pid>
jstackツールはサポートされていません。JDKの将来のバージョンで使用可能になるかどうかは未定です。
ヒープ・ダンプは、JVMヒープ内のすべてのオブジェクトの詳細情報を確認するために使用されます。この情報には、ロードされたオブジェクトのインスタンス数およびオブジェクトに割り当てられたメモリー容量が含まれます。一般的にヒープ情報は、リソースの浪費またはパフォーマンスの低下の原因となっている可能性のあるアプリケーションの部分を見つけるために使用されます。Coherenceの完全な分散環境では、アプリケーションの処理がクラスタを横断して発生し、問題となるオブジェクトは必ずしもJVMにローカルであるとはかぎらないので、ヒープ・ダンプは扱いづらくなる場合があります。ヒープ・ダンプは単なる一時のスナップショットにすぎないので、長時間で複数のダンプを収集するようにしてください。サポートの問題を送信する場合は、必ずヒープ・ダンプを含めてください。
ヒープ・ダンプを最も簡単に取得するには、プロファイル・ツールを使用します。OracleのJava VirtualVM (jvisualvm)および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の管理』を参照してください。
