アプリケーション・サーバー・プロセスが自然にクローズする場合、
または Web モジュールが新しい要求に対して応答しなくなった場合は、ただちにその理由を
調べる必要があります。以下の方法で、
これが Web モジュールの問題か、アプリケーション・サーバー環境の問題かを
判断できます。
アプリケーション・サーバー・プロセスが自然にクローズする場合、またはそのアプリケーション・サーバーで
実行中の Web モジュールが新しい要求に対して応答しなくなった場合は、以下のことを行います。
- 可能であれば、別のサーバーに Web モジュールをインストールして、
問題の切り分けを試みます。
- 製品のディレクトリー構造を調べて、javacore[number].txt のような名前の
ファイルを探します。これは Java スレッドのダンプ・ファイルで、
アプリケーション・サーバー・プロセスが自然にクローズした場合、
JVM はこのファイルを作成します。
- Tivoli Performance Viewer を使用して、
アプリケーション・サーバー・リソース (Java ヒープなど) またはデータベース接続のいずれかが最大容量に
達していないかを確認します。リソースに問題がある場合は、アプリケーション・コードを調べて
考えられる原因を探ります。
- データベース接続が要求に割り当てられていて、その要求の処理が終了しても
解放されない場合は、finally{} ブロック内で開いているすべての接続オブジェクトに対して、
アプリケーション・コードが close() を実行するようにします。
- 使用中のサーブレット・エンジンのスレッドが増加し続けている場合は、
アプリケーションの synchronized コード・ブロックにデッドロック状態がないかどうかを調べます。
- JVM のヒープ・サイズが増加し続けている場合は、
アプリケーション・コードを調べて、
オブジェクトをガーベッジ・コレクションの対象外にする可能性のある、
静的な (クラス・レベルの) コレクションなどのメモリー・リークがないかどうかを確認します。
- メモリー・リークの問題があるかどうかを調べるには、アプリケーション・サーバーで
冗長ガーベッジ・コレクションを使用可能にします。この機能によって、JVM エラー・ログ・ファイルに、
使用可能なメモリーおよび使用中のメモリーの量についての詳細な記述が追加されます。
冗長
ガーベッジ・コレクションを使用可能にするには、以下のようにします。
- 管理コンソールで、「サーバー」>「アプリケーション・サーバー」>「server_name」とクリックします。次に、「サーバー・インフラストラクチャー」で、「Java
およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」とクリックして、「冗長ガーベッジ・コレクション」を使用可能にします。
- アプリケーション・サーバーを停止して再始動します。
- 定期的にログ・ファイルを参照して、ガーベッジ・コレクションの記述がないかを調べます。「allocation failure」で始まるステートメントを探します。
このストリングは、メモリー割り振りの必要が生じたため、
JVM ガーベッジ・コレクションが起動して未使用メモリーを
解放したことを示します。割り振り失敗は正常な動作であり、必ずしも問題があることを
意味するわけではありません。ただし、割り振り失敗ステートメントに続くステートメントで、
必要なバイト数および割り振られたバイト数が表示されます。この、
必要なバイト数を表すステートメントによって、JVM 自体で使用するためにさらに多くのメモリーを
割り振り続けていることや、JVM が必要なメモリーを割り振れないことが示された場合は、
メモリー・リークが発生している可能性があります。
Tivoli Performance Viewer を
使用すると、メモリー・リーク問題を検出することもできます。
- アプリケーション・サーバーのメモリーが不足しているかどうかを
判断します。アプリケーション・サーバーがメモリー不足であると判断される場合は、
以下のいずれかの状態になっている可能性があります。
- 対処する必要のあるメモリー・リークがアプリケーション・コード内にあります。
メモリー・リークの原因を正確に突き止めるには、管理コンソールの JAVA
仮想マシンのページの「RunHProf」プロパティーを使用可能にします。
server_name は、
問題のあるアプリケーション・サーバーの名前です。「RunHProf」プロパティーを使用可能にした後に、
以下を実行してください。
- 「HProf 引数」フィールドを、depth=20,file=heapdmp.txt などの値に設定します。
この値は、最大 20 レベルまでの例外スタックを示し、ヒープ・ダンプ出力を app_server_root/bin/heapdmp.txt ファイルに保管します。
- 設定を保管します。
- アプリケーション・サーバーを停止して再始動します。
- 可能な場合は、シナリオを再現するか、アプリケーション・サーバーの処理を自然にクローズさせた原因、またはその Web モジュールが新しい要求への応答をしなくなった原因であるリソースにアクセスします。
次に、アプリケーション・サーバーを停止します。
シナリオを再現できない場合、
またはリソースにアクセスできない場合は、問題が再び発生するまで待ち、
それからアプリケーション・サーバーを停止します。
- ヒープ・ダンプの保管先のファイルを調べます。例えば、app_server_root/bin/heapdmp.txt ファイルを調べます。
- 「SITES BEGIN」というストリングを探します。
これにより、メモリー内の Java オブジェクトのリストのロケーションが分かり、
それらのオブジェクトに割り振られたメモリー量が示されます。
- Java オブジェクトのリストは、JVM 内にメモリーが割り振られるたびに作成されます。
このリストには、メモリーがインスタンス化したオブジェクトのタイプ、
およびダンプ内にリストされている、割り振りを行った Java メソッドを示すトレース・スタックの ID についてのレコードがあります。
- Java オブジェクトのリストは、割り振られたバイト数で降順に並べられています。
リークの性質に応じて、問題のクラスがリストの上部に表示されますが、必ずしも常にこのようになるわけではありません。リスト全体から、
大きなメモリーか、または頻繁に生成されている同じクラスのインスタンスを探します。
後者の場合は、trace stack 列の ID を使用して、
同じクラスおよびメソッドで繰り返し発生している割り振りを特定します。
- 関連するトレース・スタックで示されているソース・コードを調べて、メモリー・リークの可能性がないかどうかを確認します。
- JVM が、可能な限り最大のヒープ・サイズを使用しています。この場合は、
アプリケーション・サーバーの最大ヒープ・サイズ設定を増やせるだけのストレージがあれば、
この設定を増やしてください。
- サーバーのランタイムに問題があります。サーバー・ランタイムに問題があると
判断した場合は、製品のサービス・アップデートがすべて適用済みであることを
確認してください。サービス・アップデートをすべて適用しても
問題が解決しない場合は、IBM サポートに連絡してください。
- 以下のように、スレッド・ダンプをブラウズして、手掛かりを見つけます。
JVM は、
アプリケーション・サーバー・プロセスが自然にクローズすると、必ずスレッド・ダンプを作成します。
アプリケーションに、強制的にスレッド・ダンプを作成させることもできます。ダンプの作成後に
そのダンプを調べると、新しい要求がなぜ処理されなくなったかを知る手掛かりが得られます。
スレッド・ダンプを強制的に作成する手順は、次のとおりです。
- wsadmin のコマンド・プロンプトを使用して、以下のように入力し、問題のアプリケーション・サーバーの情報を取得します。
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
- スレッド・ダンプを生成します。
wsadmin>$AdminControl invoke $jvm dumpThreads
- WebSphere Application Server インストール・ルート・ディレクトリーで、javacore.date.time.id.txt のような名前の出力ファイルを探します。
アプリケーションがダンプを作成したら、それを調べることで次のような手掛かりを得ることができます。
- ファイルの先頭にある「エラー」ストリングまたは
「例外情報」ストリング。これらのストリングは、アプリケーション・サーバー・プロセスが自然にクローズする
原因となったスレッドを示しています。ダンプを強制的に作成した場合は、
これらのストリングは存在しません。
- プロセス内の各スレッドのスナップショットを確認します。スレッド・ダンプには、プロセス内の各スレッドのスナップショットが含まれています。このスナップショットは、「Full thread dump」で始まります。
- 「state:R」を含む記述を持つスレッドを探します。
このようなスレッドは、
ダンプの強制時またはプロセスの終了時にアクティブであり、実行されています。
- 同じ Java アプリケーションのコード・ソースの場所で、複数のスレッドを探します。
同じ場所からの複数のスレッドは、
デッドロック状態 (複数のスレッドがモニター上で待機している) か無限ループを示している可能性があり、
問題のあるアプリケーション・コードを識別するのに役立ちます。
IBM からのトラブルシューティングのヘルプ
の説明のとおり、IBM サポートが提供する資料およびツールを利用することによって、問題の解決に必要な情報収集の時間が節約できます。
問題報告書を開く前に、以下のサポート・ページを参照してください。