WebSphere Application Server Network Deployment, Version 6.1   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

メモリー不足エラーおよび Java ヒープ・メモリー・リークの診断

Memory Dump Diagnostic for Java™ は、Java ヒープにおいて、メモリー・リークの背後にある根本原因を診断するためのオフライン・ツールです。このツールは、WebSphere® Application Server が実行されている Java 仮想マシン (JVM) からのメモリー・ダンプ (ヒープ・ダンプ) に共通の形式を分析します。 メモリー・ダンプの分析の目標は、メモリー・リークの根本原因となっている可能性のある Java ヒープ内のデータ構造を識別することです。 またこの分析は、アプリケーションの Java ヒープ・フットプリントに大きく貢献するオブジェクト・グループの要約されたセットも識別します。 このツールは、メモリー不足問題が発生している実稼働環境のアプリケーション・サーバーからの、非常に大きなメモリー・ダンプを分析することができます。

始める前に

このツールは WebSphere Application Server から生成されたメモリー・ダンプを扱うものであって、Java 用メモリー・ダンプ診断ツールから生成されたメモリー・ダンプを扱うものではありません。 以下のダンプ形式をサポートしています。
  • [AIX] [Linux] [Windows] ほとんどのプラットフォーム上の WebSphere Application Server バージョン 5.1.x 以降の場合、IBM® ポータブル・ヒープ・ダンプ (.phd)
  • [AIX] [Linux] [Windows] ほとんどのプラットフォーム上の WebSphere Application Server バージョン 4.x および 5.0.x の場合、IBM テキスト
  • [HP-UX] [Solaris] HP-UX プラットフォームおよび Solaris プラットフォーム上の WebSphere Application Server インストール環境の場合、HPROF

このタスクについて

メモリー・リークは、参照が必要なくなった後もオブジェクト参照が無意識に保留されている場合に、Java アプリケーション内で発生する場合があります。 この問題は、明示的にオブジェクトの割り振り解除を行う責任からプログラマーを解放するガーベッジ・コレクション・メカニズムが Java 言語に組み込まれていても、Java ガーベッジ・コレクション・プロセスによるメモリーの解放の妨げとなります。 大きく複雑な Java アプリケーションでは、メモリー・リークの診断は困難です。これは、Java ヒープ内に多数のオブジェクトが存在すること、および、それらのオブジェクト間の関係が複雑なことが原因です。

単一のダンプの分析、および 2 つのダンプの比較分析の 2 タイプの分析メカニズムが使用可能です。 このツールは、疑わしいデータ構造およびデータ型をリストし、メモリー・ダンプの内容を、対話式ブラウザーをベースにした Web アプリケーションに表示します。 このツールは、同様のオーナーシップ構造を持つデータ型の大きなセットをグラフィカルにレイアウトする、フットプリント分析を表示します。 このツールは、メモリー・ダンプの内容を参照用の対話式ツリー・ビュー、およびオブジェクトとデータ型の 2 つのテーブル・ビューに表示します。 ツリー・ビューによって、各オブジェクトに対して入力および出力されるすべての参照を探すことができ、また各データ構造内のメモリー・リークの疑いがあるコンテナー・オブジェクトの場所を表示できます。

オフラインでメモリー・ダンプを分析する方法は、メモリー・リークの根本原因を識別するためのオーバーヘッドの少ないメカニズムです。 このメカニズムは、大規模なアプリケーションが製品内またはストレス・テスト環境で実行され、メモリー・リークが頻繁に最初に検出される場合に特に適しています。

プロシージャー

  1. IBM サポート・アシスタントを、分析するアプリケーション・サーバーがインストールされているのとは別のコンピューターにインストールします。 最低 5 ギガバイト (GB) の空きディスク・スペース、最低 1.5 GB の RAM、および 2 GHz 以上の速さで実行される Intel® プロセッサーを持ち、できれば Linux® プラットフォーム上にある非実働コンピューターを使用します。
  2. 分析するアプリケーション・サーバーのインストール済み環境で冗長ガーベッジ・コレクションを使用可能にします。

    冗長ガーベッジ・コレクション情報は、基本的な構成の問題やメモリー・リーク問題を、フラグメント化またはネイティブ・メモリー・リークから除外するのに役立ちます。 IBM プラットフォームで冗長ガーベッジ・コレクションを使用可能にする方法については、IBM developer kits: Diagnosis documentation を参照してください。

  3. オプション: WebSphereApplication Server で単純なメモリー・リーク検出を使用可能にします。

    単純なメモリー・リーク検出を使用可能にすることは、異常なメモリー使用の振る舞いを早期に検出し、ヒープ・ダンプを自動的にトリガーするために役立ちます。

  4. WebSphere Application Server に対して JVM ヒープ・ダンプ機能を使用可能にします。

    IBM サポート・アシスタントから開始する場合は、ツールに同梱されている資料を参照してください。

  5. ヒープ・ダンプが使用可能な場合は、Java 用メモリー・ダンプ診断ツールを実行します。
    1. IBM サポート・アシスタントを始動します。
    2. IBM サポート・アシスタントで、「ツール」 タブを選択します。
    3. 左側の「WebSphere 6.1」をクリックします。
    4. 右側の「Java 用メモリー・ダンプ診断」をクリックします。

結果

考えられるメモリー・リークの根本原因が示されます。

Java ヒープ内のメモリー・リークは、ログ・ファイル内に java.lang.OutOfMemoryError 例外を作成します。 ただし、すべてのメモリー不足エラーが Java ヒープ・メモリー・リークによって引き起こされるわけではありません。 メモリー不足エラーは、以下の状態も原因となります。
  • Java ヒープ・フラグメント。 このフラグメント化は、Java に割り当てるための連続する空き Java ヒープ・スペースのチャンク (大きい塊) がない場合に発生します。 この問題には、pinned/dosed オブジェクトの存在など、さまざまな原因があります。 また、大きなオブジェクトを繰り返し割り振ることも原因となります。
  • ネイティブ・ヒープ内のメモリー・リーク。 この問題は、DB2® 接続などのネイティブ・コンポーネントにリークがある場合に発生します。

これらの状態はどちらも、大きな空き Java ヒープ・スペースがあるにもかかわらず発生するメモリー不足エラーです。したがって、Java 用メモリー・ダンプ診断ツールは、こうした状態の根本原因の検出には有効でない場合があります。




関連タスク
IBM サポート・アシスタントの取得
自動化ヒープ・ダンプ生成の使用可能化
問題の診断 (診断ツールを使用)
関連情報
IBM developer kits: Diagnosis documentation
タスク・トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 7:44:53 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/ttrb_mdd4j.html