Web モジュールまたはアプリケーション・サーバーが要求の処理を停止する

アプリケーション・サーバー・プロセスが自然にクローズする場合、 または Web モジュールが新しい要求に対して応答しなくなった場合は、ただちにその理由を 調べる必要があります。以下の方法で、 これが Web モジュールの問題か、アプリケーション・サーバー環境の問題かを 判断できます。

アプリケーション・サーバー・プロセスが自然にクローズする場合、またはそのアプリケーション・サーバーで 実行中の Web モジュールが新しい要求に対して応答しなくなった場合は、以下のことを行います。
  • 可能であれば、別のサーバーに Web モジュールをインストールして、 問題の切り分けを試みます。
  • [AIX Solaris HP-UX Linux Windows]製品のディレクトリー構造を調べて、javacore[number].txt のような名前の ファイルを探します。これは Java™ スレッドのダンプ・ファイルであり、 アプリケーション・サーバー・プロセスが自然にクローズした場合、JVM によって作成されます。
  • [z/OS]アプリケーション・サーバーのプロセスが自然にクローズする場合は、 分析の対象となる SDUMP が存在します。
  • Tivoli® Performance Viewer を使用して、 アプリケーション・サーバー・リソース (Java ヒープなど) またはデータベース接続のいずれかが最大容量に 達していないかを確認します。リソースに問題がある場合は、アプリケーション・コードを調べて 考えられる原因を探ります。
    • データベース接続が要求に割り当てられていて、その要求の処理が終了しても 解放されない場合は、finally{} ブロック内で開いているすべての接続オブジェクトに対して、 アプリケーション・コードが close() を実行するようにします。
    • 使用中のサーブレット・エンジンのスレッドが増加し続けている場合は、 アプリケーションの synchronized コード・ブロックにデッドロック状態がないかどうかを調べます。
    • JVM のヒープ・サイズが増加し続けている場合は、 アプリケーション・コードを調べて、 オブジェクトをガーベッジ・コレクションの対象外にする可能性のある、 静的な (クラス・レベルの) コレクションなどのメモリー・リークがないかどうかを確認します。
  • メモリー・リークの問題があるかどうかを調べるには、アプリケーション・サーバーで 冗長ガーベッジ・コレクションを使用可能にします。この機能によって、JVM エラー・ログ・ファイルに、 使用可能なメモリーおよび使用中のメモリーの量についての詳細な記述が追加されます。
    冗長 ガーベッジ・コレクションを使用可能にするには、以下のようにします。
    1. [AIX Solaris HP-UX Linux Windows][IBM i]管理コンソールで、「サーバー」 > 「サーバー・タイプ」 > 「アプリケーション・サーバー」server_name とクリックします。次に、「サーバー・インフラストラクチャー」で、 > 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」をクリックし、「冗長ガーベッジ・コレクション」を選択します。
    2. [z/OS]管理コンソールで、「サーバー」 > 「サーバー・タイプ」 > 「アプリケーション・サーバー」server_name とクリックします。次に、「サーバー・インフラストラクチャー」セクションで、 > 「Java およびプロセス管理」 > 「プロセス定義」 > 「Java 仮想マシン」をクリックし、「冗長ガーベッジ・コレクション」を選択します。
    3. アプリケーション・サーバーを停止して再始動します。
    4. 定期的にログ・ファイルを参照して、ガーベッジ・コレクションの記述がないかを調べます。「allocation failure」で始まるステートメントを探します。このストリングは、メモリー割り振りの必要が生じたため、 JVM ガーベッジ・コレクションが起動して未使用メモリーを 解放したことを示します。割り振り失敗は正常な動作であり、必ずしも問題があることを 意味するわけではありません。ただし、割り振り失敗ステートメントに続くステートメントで、 必要なバイト数および割り振られたバイト数が表示されます。この、 必要なバイト数を表すステートメントによって、JVM 自体で使用するためにさらに多くのメモリーを 割り振り続けていることや、JVM が必要なメモリーを割り振れないことが示された場合は、 メモリー・リークが発生している可能性があります。

    [AIX Solaris HP-UX Linux Windows][IBM i]Tivoli Performance Viewer を使用すると、 メモリー・リーク問題を検出することもできます。

  • [AIX Solaris HP-UX Linux Windows]アプリケーション・サーバーのメモリーが不足しているかどうかを 判断します。アプリケーション・サーバーがメモリー不足であると判断される場合は、 以下のいずれかの状態になっている可能性があります。
    • 対処する必要のあるメモリー・リークがアプリケーション・コード内にあります。 メモリー・リークの原因を正確に突き止めるには、管理コンソールの 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® サポートに連絡してください。
  • [AIX Solaris HP-UX Linux Windows][IBM i]以下のように、スレッド・ダンプをブラウズして、手掛かりを見つけます。

    JVM は、 アプリケーション・サーバー・プロセスが自然にクローズすると、必ずスレッド・ダンプを作成します。 アプリケーションに、強制的にスレッド・ダンプを作成させることもできます。ダンプの作成後に そのダンプを調べると、新しい要求がなぜ処理されなくなったかを知る手掛かりが得られます。

    スレッド・ダンプを強制的に作成する手順は、次のとおりです。

    1. wsadmin のコマンド・プロンプトを使用して、以下のように入力し、問題のアプリケーション・サーバーの情報を取得します。
      wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server_name,*] 

      ここで、server_name はサーバーの名前です。

    2. スレッド・ダンプを生成します。
      wsadmin>$AdminControl invoke $jvm dumpThreads
      注: dumpThreads コマンドは、-Xdumps の設定に応じて他のタイプのダンプ・ファイルを作成します。ダンプの出力はプラットフォームに応じて異なり、システムのコア・ファイル、ヒープ、およびスナップ・ダンプを含んでいることがあります。
    3. [IBM i]profile_root/logs ディレクトリーで、javacore.jobnum.jobuser.jobname.timestamp.txt のような名前の出力ファイルを探します。
    4. [AIX Solaris HP-UX Linux Windows]製品のインストール・ルート・ディレクトリーで、javacore.date.time.id.txt のような名前の出力ファイルを探します。

    アプリケーションがダンプを作成したら、それを調べることで次のような手掛かりを得ることができます。

    • [AIX Solaris HP-UX Linux Windows]ファイルの先頭にある「エラー」ストリングまたは 「例外情報」ストリング。これらのストリングは、アプリケーション・サーバー・プロセスが自然にクローズする 原因となったスレッドを示しています。ダンプを強制的に作成した場合は、 これらのストリングは存在しません。
    • [IBM i]過剰な現在のヒープ・サイズを探します。 スレッド・ダンプは、現在の Java ヒープ・サイズ、およびヒープ・サイズの最大および最小設定に関する情報を示します。
    • [AIX Solaris HP-UX Linux Windows]プロセス内の各スレッドのスナップショットを確認します。スレッド・ダンプには、プロセス内の各スレッドのスナップショットが含まれています。このスナップショットは、「Full thread dump」で始まります。
      • 「state:R」を含む記述を持つスレッドを探します。 このようなスレッドは、 ダンプの強制時またはプロセスの終了時にアクティブであり、実行されています。
      • 同じ Java アプリケーションのコード・ソースの場所で、複数のスレッドを探します。 同じ場所からの複数のスレッドは、 デッドロック状態 (複数のスレッドがモニター上で待機している) か無限ループを示している可能性があり、 問題のあるアプリケーション・コードを識別するのに役立ちます。
    • [IBM i]プロセス内の各スレッドのスナップショットを確認します。スレッド・ダンプには、プロセス内の各スレッドのスナップショットが含まれています。このスナップショットは、「Thread Information」というセクションから始まります。
      • 他のスレッドが保持しているロックを待機しているスレッドを探します。
      • 同じ Java アプリケーションのコード・ソースの場所で、複数のスレッドを探します。 同じ場所からの複数のスレッドは、 デッドロック状態 (複数のスレッドがモニター上で待機している) か無限ループを示している可能性があり、 問題のあるアプリケーション・コードを識別するのに役立ちます。

        通常、製品ランタイムの特定のコンポーネントには、同じ Java コード・ソース・ロケーションに特定のタイプのスレッドがあります。 これらのコンポーネントとしては、Web コンテナー、EJB コンテナー、および orb スレッド・プールがあります。

IBM サポートが提供する資料とツールを利用すれば、 問題解決に必要な情報を集める時間を節約できます。 問題報告書を開く前に、以下のサポート・ページを参照してください。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_appdies
ファイル名:rtrb_appdies.html