アプリケーション・サーバー・プロセスが自然にクローズする場合、
または Web モジュールが新しい要求に対して応答しなくなった場合は、ただちにその理由を
調べる必要があります。以下の方法で、
これが Web モジュールの問題か、アプリケーション・サーバー環境の問題かを
判断できます。
アプリケーション・サーバー・プロセスが自然にクローズする場合、またはそのアプリケーション・サーバーで
実行中の Web モジュールが新しい要求に対して応答しなくなった場合は、以下のことを行います。
- 可能であれば、別のサーバーに Web モジュールをインストールして、
問題の切り分けを試みます。
- Tivoli Performance Viewer を使用して、
アプリケーション・サーバー・リソース (Java ヒープなど) またはデータベース接続のいずれかが最大容量に
達していないかを確認します。リソースに問題がある場合は、アプリケーション・コードを調べて
考えられる原因を探ります。
- データベース接続が要求に割り当てられていて、その要求の処理が終了しても
解放されない場合は、finally{} ブロック内で開いているすべての接続オブジェクトに対して、
アプリケーション・コードが close() を実行するようにします。
- 使用中のサーブレット・エンジンのスレッドが増加し続けている場合は、
アプリケーションの synchronized コード・ブロックにデッドロック状態がないかどうかを調べます。
- JVM のヒープ・サイズが増加し続けている場合は、
アプリケーション・コードを調べて、
オブジェクトをガーベッジ・コレクションの対象外にする可能性のある、
静的な (クラス・レベルの) コレクションなどのメモリー・リークがないかどうかを確認します。
- メモリー・リークの問題があるかどうかを調べるには、アプリケーション・サーバーで
冗長ガーベッジ・コレクションを使用可能にします。この機能によって、JVM エラー・ログ・ファイルに、
使用可能なメモリーおよび使用中のメモリーの量についての詳細な記述が追加されます。
冗長
ガーベッジ・コレクションを使用可能にするには、以下のようにします。
- 管理コンソールで、「サーバー」>「アプリケーション・サーバー」>「server_name」とクリックします。次に、「サーバー・インフラストラクチャー」で、「Java
およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」とクリックして、「冗長ガーベッジ・コレクション」を使用可能にします。
- アプリケーション・サーバーを停止して再始動します。
- 定期的にログ・ファイルを参照して、ガーベッジ・コレクションの記述がないかを調べます。「allocation failure」で始まるステートメントを探します。
このストリングは、メモリー割り振りの必要が生じたため、
JVM ガーベッジ・コレクションが起動して未使用メモリーを
解放したことを示します。割り振り失敗は正常な動作であり、必ずしも問題があることを
意味するわけではありません。ただし、割り振り失敗ステートメントに続くステートメントで、
必要なバイト数および割り振られたバイト数が表示されます。この、
必要なバイト数を表すステートメントによって、JVM 自体で使用するためにさらに多くのメモリーを
割り振り続けていることや、JVM が必要なメモリーを割り振れないことが示された場合は、
メモリー・リークが発生している可能性があります。
Tivoli Performance Viewer を
使用すると、メモリー・リーク問題を検出することもできます。
- 以下のように、スレッド・ダンプをブラウズして、手掛かりを見つけます。
JVM は、
アプリケーション・サーバー・プロセスが自然にクローズすると、必ずスレッド・ダンプを作成します。
アプリケーションに、強制的にスレッド・ダンプを作成させることもできます。ダンプの作成後に
そのダンプを調べると、新しい要求がなぜ処理されなくなったかを知る手掛かりが得られます。
スレッド・ダンプを強制的に作成する手順は、次のとおりです。
- wsadmin のコマンド・プロンプトを使用して、以下のように入力し、問題のアプリケーション・サーバーの情報を取得します。
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
- スレッド・ダンプを生成します。
wsadmin>$AdminControl invoke $jvm dumpThreads
- profile_root/logs ディレクトリーで、javacore.jobnum.jobuser.jobname.timestamp.txt のような名前の出力ファイルを探します。
アプリケーションがダンプを作成したら、それを調べることで次のような手掛かりを得ることができます。
- 過剰な現在のヒープ・サイズを探します。
スレッド・ダンプは、現在の Java ヒープ・サイズ、およびヒープ・サイズの最大および最小設定に関する情報を示します。
- プロセス内の各スレッドのスナップショットを確認します。スレッド・ダンプには、プロセス内の各スレッドのスナップショットが含まれています。このスナップショットは、「Thread Information」というセクションから始まります。
IBM からのトラブルシューティングのヘルプ
の説明のとおり、IBM サポートが提供する資料およびツールを利用することによって、問題の解決に必要な情報収集の時間が節約できます。
問題報告書を開く前に、以下のサポート・ページを参照してください。