| Oracle® JRockit診断およびトラブルシューティング・ガイド リリースR28 B61438-02 |
|
 前 |
 次 |
JRockit JVMまたはJavaアプリケーションがクラッシュしていないのに応答しなくなった場合は、フリーズしていると考えられます。つまり、アプリケーションはリクエストに応答しませんが、プロセスはまだ存在しています。
この章では、JVMのフリーズの診断方法と、Oracleサポート担当者が問題を解決する場合に不可欠な情報の収集方法を説明します。
この章の内容は以下のとおりです。
システムはJVMまたはアプリケーションのどちらかでフリーズする可能性があります。フリーズがアプリケーションとJVMのどちらで起きているのかを確認するには、スレッド・ダンプの生成を試行します。
Windowsの場合、[Ctrl]+[Break]を押します。
LinuxおよびSolarisの場合、親JavaプロセスIDにSIGQUIT (kill -3)を送信します。
|
注意: すべてのプラットフォームで、jrcmdを使用してスレッド・ダンプを取得することもできます。例:
jrcmd nnnn "print_threads nativestack=true"
|
システムでJavaスレッド・ダンプの応答があった場合は、アプリケーションがフリーズしています。このタイプのフリーズのトラブルシューティングについては、7.2項「Javaアプリケーションのフリーズのトラブルシューティング」を参照してください。
スレッド・ダンプを取得できない場合は、JVMがフリーズしています。このタイプのフリーズのトラブルシューティングについては、7.3項「JVMのフリーズのトラブルシューティング」を参照してください。
スレッド・ダンプでロックとデッドロックについて(スレッド・ダンプの末尾近くを調べて)確認します。
フリーズの原因を特定できない場合、または問題を自力で簡単に解決できない場合は、アプリケーションの開発者に連絡します。
ユーザーと同様にアプリケーション開発者も問題を診断できない場合は、第9章「サポートに関するオラクルへの連絡」の説明に従ってOracleサポートにご連絡ください。Javaアプリケーションのフリーズに関するOracleサポートへのご連絡の際は、次の情報をご提供ください。
アプリケーションが正常に動作しているときのスレッド・ダンプを3つ
アプリケーションがフリーズしたときのスレッド・ダンプを3つ
アプリケーションが正常に動作しているときの120秒間のフライト・レコーダ記録を1つ
アプリケーションがフリーズしたときの120秒間のフライト・レコーダ記録を1つ
[Ctrl]+[Break]を使用する方法、または親JavaプロセスIDにSIGQUIT (kill -3)を送信する方法を何度か試みてもスレッド・ダンプを取得できない場合、JVMはシグナルの処理を停止してフリーズしています。
このような場合は、JVMを強制的にクラッシュさせてからOracleサポートにご連絡ください。クラッシュ・ファイルは、Oracleサポート担当者が問題を診断および解決する場合に不可欠です。
この項では、フリーズしたJRockit JVMを強制的にクラッシュする方法について説明します。内容は次のとおりです。
LinuxシステムでフリーズしたJRockit JVMを強制的にクラッシュするには、SIGABRTシグナルを送信します。これによってプロセスが中断されてクラッシュが発生し、結果としてクラッシュ・ファイルが作成されます。
SIGABRTを呼び出すには次の手順を実行します。
JRockit JVMプロセスのプロセスIDを見つけるには、次のコマンドを実行します。
|
注意: 下記の手順はカーネル2.6ベースのLinuxシステムおよびRed Hat Enterprise Linux 3.0(またはそれ以降のバージョン)で有効です。 |
pstree -p user | grep java
このコマンドで、userはJRockit JVMプロセスの実行に使用されるLinuxのユーザー名です(例: webadmin)。
コマンドによって大量の出力が生じる場合は、まずunset LANGを実行することでLANG環境変数のunsetを試行します。
コマンドでJavaプロセスが1つだけ表示される場合は、ステップ2に進みます。
コマンドによって複数のプロセスが表示される場合は、次のコマンドを実行して、必要なプロセスのコマンドライン・パラメータを出力します。
cat /proc/nnnn/cmdline | xargs --null -n1 echo
このコマンドで、nnnnはJRockit JVMプロセスのIDです。
このコマンドでは、指定したJVMプロセスのコマンドライン・オプションが表示されます。いずれかのコマンドライン・オプションが問題の原因ではないかチェックします。
プロセスのバイナリ・クラッシュ・ファイル(.core)が作成されるディレクトリを見つけるには、次のコマンドを入力します。
ls -l /proc/nnnn/cwd
このコマンドで、nnnnはJRockit JVMプロセスのIDです。
バイナリ・クラッシュ・ファイルを作成(およびプロセスを終了)するには、次のコマンドを実行します。
ulimit -c unlimited
kill -SIGABRT nnnn
このコマンドで、nnnnはJRockit JVMプロセスのIDです。
WindowsシステムでフリーズしたJRockit JVMを強制的にクラッシュするには、windbgコマンドを次のように使用します。
windbg.exe -Q -pd -p nnnn -c ".dump /u /ma hung.mdmp; q"
このコマンドで、nnnnはJRockit JVMプロセスのIDです。
|
注意: windbgは以下のURLからダウンロード可能なWindows用デバッグ・ツール・パッケージに含まれています。
|
JRockit JVMをサービスとして起動した場合は、次のいずれかの方法でスレッド・ダンプを収集できます。
自分のマシンから情報を収集する場合は、print_threads診断コマンドとともにjrcmdを実行します。
jrcmdコマンドの詳細は、Oracle JRockit JDKツールを参照してください。
別のマシンから情報を収集する場合は、diagnostics BeanとともにOracle JRockit Mission Controlを使用します。詳細は、Oracle JRockit Mission Controlオンライン・ヘルプを参照してください。
JRockit JVMをOracle WebLogic Serverで実行している場合は、beasvc –dumpを使用してJVMからスレッド・ダンプを取得します。
詳細は、Oracle WebLogic Server のドキュメントを参照してください。
サーバー・インスタンスがstdoutとstderrに書き込むメッセージ(スタック・トレースとスレッド・ダンプを含む)を参照するには、stdoutとstderrをファイルにリダイレクトします。Oracle WebLogic Serverのドキュメントを参照してください。
WebLogic Serverインスタンスからstdoutにスレッド・ダンプを書き込むには、次のいずれかの操作を行います。
weblogic.Admin THREAD_DUMPコマンドを使用します。
コマンド・プロンプトに次のコマンドを入力します。
WL_HOME\bin\beasvc -dump -svcname:service-name
このコマンドで、WL_HOMEはWebLogic Serverのインストール先のディレクトリです。service-nameはサーバー・インスタンスを実行しているWindowsサービスです。例:
D:\Oracle\Middleware\wlserver_10.3\server\bin\beasvc -dump -svcname:mydomain_myserver
