Comments
Transcript
4 4-1 IBM Support Assistant V4.0 4-2 WAS
4 問題判別 .................................................................................................................................. 2 4-1 IBM Support Assistant V4.0 の概要 ............................................................................... 2 4-2 WAS 構成情報の収集.......................................................................................................... 4 4-2-1 ISA Lite for WAS のアドオン ............................................................................................ 5 4-2-2 コレクター・ツールによる情報の収集 ............................................................................... 8 4-3 JVM 診断ツール ................................................................................................................. 11 4-3-1 JVM 診断ツールのアドオン............................................................................................. 12 4-3-2 診断ツールによる問題判別............................................................................................ 15 4-3-3 IBM Thread and Monitor Dump Analyzer (TMDA) .................................................... 20 4-3-4 IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT)..... 23 1 4 問題判別 この章では、IBM Support Assistant V4.0（以下、ISA）を利用した問題判別を行う際の考慮点につい て説明します。 ISA は、QA や問題の調査を手助けする無料ツールです。WEB サイトからダウンロードすることができ るほか、｢WebSphere Application Server V7.0｣の CD を利用して、インストールすることができます。WAS 同梱版は、「Java 用メモリー・ダンプ診断」ツールを標準で装備しています。さらに、検索対象サイトに Information Center を追加してあるなど WAS 利用者にとって役立つようになっています。 ４-1 では ISA の概要、4-2 では WAS 製品の問題判別、4-3 ではメモリー・リーク発生時やパフォーマ ンス・チューニングに役立つ問題判別について説明していきます。 4-1 IBM Support Assistant V4.0 の概要 IBM Support Assistant は、以下３つの要素で構成されます。なお、ISA Assistant Agent と ISA Agent Manager はオプションですが、リモートで操作する際には必ず必要となるコンポーネントです。次頁の 「図 4-1 ISA 全体概要図」とともに、ご確認ください。 • ISA Workbench ISA Workbench (以降、ワークベンチあるいは Workbench) は、問題判別を行うクライアント・サイド・ アプリケーションです。ワークベンチを使用して、情報の検索、問題分析と診断、サービス要求の送信と 管理を行うことができます。また、リモートで操作する場合は、ISA Agent Manager およびネットワーク内 のリモート・マシン上の ISA Agent と対話し、リモート・マシン上でリモート・システム・ファイル転送や、 データ収集、インベントリー・レポート作成などのフィーチャーを使用することができます。 • ISA Assistant Agent IBM Support Assistant Agent (以降、エージェントあるいは Agent) は、リモートでトラブルシューティン グする必要がある際に、対象サーバーにインストールします。インストールが成功すると、ISA Agent Manager に登録されます。 • ISA Agent Manager ISA Agent Manager(以降、エージェント・マネージャーあるいは Agent Manager) は、エージェントの 情報を保管します。また、認証局としての役割も提供します。すべてのエージェントは、エージェント・マ ネージャーに登録される必要があります。エージェント・マネージャーはオプションですが、エージェント をインストールする場合は、必ず事前に、エージェント・マネージャー をインストールしておきます。 エージェント・マネージャーは、エージェントと同じシステムにインストールすることも、専用のシステム にインストールすることもできます。エージェント・マネージャーは、ご使用のネットワークに「1 回のみ」イ ンストールする必要があります。 2 図 4-1 ISA 全体概要図 ISA の構成は、図 4-1 が示すとおり、１つのエージェント・マネージャーと、複数のエージェントで構成 することができます。また、エージェントを導入したサーバーの情報の検索、問題分析は、ワークベンチ から行います。ワークベンチを起動すると、初めにエージェント・マネージャーが認証を行い、使用可能 なすべての エージェント のリストを取得します。この後、ワークベンチ は エージェント と直接対話で きるようになります。 図 4-2 ISA Workbench 初期画面（ウェルカム・ページ） 3 4-2 WAS 構成情報の収集 「IBM Support Assistant Lite for WebSphere Application Server(以降、ISA Lite for WAS)」は、WAS の情報を収集するために用意された ISA 拡張機能です。ISA Lite for WAS を利用することで、サーバー にログインすることなく、ISA リモート機能を利用して、WAS に関する情報を収集することができます。こ の機能を利用するには、ワークベンチに ISA Lite for WAS をアドオンする必要があります。 以降の手順では、ワークベンチ、エージェント・マネージャー、対象サーバーのエージェントがインスト ール済みであること、エージェント・マネージャー、エージェントが起動している必要があります。 ISA の各コンポーネントのインストール方法については以下のサイトを参考にしてください。 ●Infromation Center : Software support IBM Support Assistant（英語） http://www-01.ibm.com/software/support/isa/ エージェント・マネージャーの起動方法 <agent_manager_root>/AppServer/bin/startServer.sh(bat) AgentManager 【確認方法】 以下のようなメッセージが返されます。 ADMU0116I: ツール情報はファイル /opt/IBM/AgentManager/AppServer/agentmanager/logs/AgentManager/startServer.log に記録されています ADMU0128I: agentmanager プロファイルを使用してツールを開始しています ADMU3100I: サーバーの構成を読み取ります: AgentManager ADMU3200I: サーバーが起動しました。 開始処理中です。 ADMU3000I: サーバー AgentManager が e-business 用にオープンされました。プロセス ID は 770196 です エージェントの起動方法 <agent_root>/runtime/nonstop/bin/nonstopservice.sh(bat) start 【確認方法】 以下のようなメッセージが返されます。「The LWI Nonstop Profile successfully started」というメッセージ を確認してください。 Starting The LWI Nonstop Profile... The LWI Nonstop Profile succesfully started. Please refer to logs to check the LWI status. 4 エージェント・マネージャーおよびエージェントの停止方法を紹介します。停止する必要がある場合は、 次の手順に沿って停止してください。 エージェント・マネージャーの停止方法 <agent_manager_root>/AppServer/bin/stopServer.sh(bat) AgentManager 【確認方法】 以下のようなメッセージが返されます。 ADMU0116I: ツール情報はファイル /opt/IBM/AgentManager/AppServer/agentmanager/logs/AgentManager/stopServer.log に記録されています ADMU0128I: agentmanager プロファイルを使用してツールを開始しています ADMU3100I: サーバーの構成を読み取ります: AgentManager ADMU3201I: サーバーの停止要求が出されました。 停止処理中です。 ADMU4000I: サーバー AgentManager の停止が完了しました。 エージェントの停止方法 <agent_root>/runtime/nonstop/bin/nonstopservice.sh(bat) stop 【確認方法】 以下のようなメッセージが返されます。「Stopped The LWI Nonstop Profile」というメッセージを確認してく ださい。 Stopping The LWI Nonstop Profile... Waiting for The LWI Nonstop Profile to exit... Waiting for The LWI Nonstop Profile to exit... Waiting for The LWI Nonstop Profile to exit... Stopped The LWI Nonstop Profile. 4-2-1 ISA Lite for WAS のアドオン ISA Lite for WAS を ISA に設定（アドオン）する方法について説明します。ISA は WAS に限らず、 IBM ソフトウェア製品の問題判別に利用されるため、ISA をインストールした状態では、WAS の問題判 別する機能が含まれていません。WAS の問題判別を実施するには、別途、機能のアドオンが必要となり ます。 1). ワークベンチを起動します。メニュー・バーから[管理]→[Remote Agent]→[新規アドオンをロー カル・リポジトリにダウンロード]をクリックします。 5 2). インストールする製品の中から、[ＷebSphere Application Server V7.0]を選択します。[次へ] をクリックします。ライセンス画面が表示されます。[すべての使用条件の条項に同意します]を選 択し、[次へ]をクリックします。 図 4-3 ISA Lite for WAS のインストール：製品の選択 3). 要約が表示されます。[終了]をクリックすると、インストールが開始されます。完了すると、[成功]と 表示されます。 図 4-4 ISA Lite for WAS のインストール：要約の表示 4). ワークベンチのリポジトリから、各リモート・サーバーの情報が収集できるよう設定します。[管理] →[Remote Agent]→[アドオンを Agent にインストール]をクリックし、対象とするサーバーを選択 します。 6 5). アドオンが完了したことを確認します。ワークベンチのホームから[問題分析]→[データの収集]→ [コレクターの選択]→[server_name]を選択します。[WebSphere Applicaton Server 7.0]のツ リーが表示されます。 図 4-5 ISA Lite for WAS の表示画面 7 4-2-2 コレクター・ツールによる情報の収集 「4-2-1ISA Lite for WAS のアドオン」で設定した機能のうち、「Collect Product Information（以降、コレ クター・ツール）」について説明します。これは従来の<WAS_root>/bin/collector.sh(.bat)コマンド機能と同 等です。（WAS V7.0 より collector コマンドは非推奨となりました。） コレクター・ツールは、WAS の構成情報を 収集し、IBM カスタマー・サポートに送信可能な Java ア ーカイブ (JAR) ファイルにパッケージ化します。 JAR ファイル内の情報には、ログ、プロパティー・ファ イル、構成ファイル、 オペレーティング・システムと Java のデータ、および前提条件となる各ソフトウェ アの有無とレベルが含まれます。コレクター・ツールの情報は主に、IBM カスタマー・サポートで利用し ます。 1). ワークベンチを起動します。メニュー・バーから、[アクティビティの起動]→[問題判別]→[データ収 集]を選択します。 図 4-6 ISA Workbench 問題分析の起動 2). 対象サーバーをプルダウン・リストより選択します。ID とパスワードを求められます。ここでは、サ ーバーの ID、パスワードを入力します。 図 4-7 ISA Workbench 対象サーバーの選択 8 3). [WebSphere Application Server 7.0]→[General] →[RAS Collector Tool]を選択し、[追加] ボタンをクリックします。[コレクター・キュー]に対象サーバーが追加されたことを確認します。 図 4-8 ISA Workbench コレクター・キュー追加画面 4). [すべて収集]ボタンをクリックします。[ユーザー入力]が表示されます。以下のステップを踏んで、 必要な情報を入力します。入力後、[OK]をクリックすると、ステップが進みます。 Collection file name :データ収集ファイルは zip 形式で、一時的にサーバーに置かれま す 。 zip フ ァ イ ル を 一 時 的 に 置 く テ ン ポ ラ リ ー ・ エ リ ア を 指 定 し ま す 。 <temp_dir>/<collector_tool>.zip の形式で指定します。 図 4-9 ステップ１ テンポラリー・エリアの指定 9 WebSphere Application Server root directory :<WAS_root>を指定します。 図 4-10 ステップ２ WAS のインストール・ディレクトリを指定 IBM カスタマー・サポートに送付するテキスト形式のファイルを作成することができます。 [Yes]を選択すると、テキストにコメントを記載することができます。[No]を選択すると、テキ ストファイルは作成されません。このテキストファイルは、ZIP ファイルに、収集データとは 別のフォルダに保管されます。 5). 作成された zip ファイルはファイル・ストレージ・ディレクトリーに保管されます。（ファイル・ストレー ジ・ディレクトリーは[プリファレンス]→[ファイル・ストレージ・ディレクトリー]で指定することができ ます。）作成された zip ファイルの中に、<host_name-cell_name-node_name-profile_name.jar> が保管されています。ファイルを IBM カスタマー・サポートに送信し、分析を依頼してください。 10 4-3 JVM 診断ツール ISA に診断ツールをアドオンし、問題判別を行うことができます。ここでは、Java 仮想マシン（JVM）に 関する３つのツールを説明します。 • Java 用メモリー・ダンプ診断 (MDD4J) Java 用メモリー・ダンプ診断ツール（MDD4J）は、WAS アプリケーションなどの Java 仮想マシン (JVM) からのメモリー・ダンプ (ヒープ・ダンプ)を分析します。メモリー・リークや OutOfMemoryError が 発生した際に、根本原因となっている可能性の高いデータ構造を識別することができます。 「単一ダンプ分析」では、ヒープ・サイズに最も影響を与える「オブジェクト・タイプ（インスタンス数、バイ ト）」「パッケージ（インスタンス数）」を識別します。 また、OutOfMemoryError が発生した際に、自動で出力されるメモリー・ダンプは、非常に大きなサイ ズとなりますが、分析することができます（2GB 以上の RAM が必要になります）。（システム要件: RAM: 1GB 以上、ディスク・スペース: 4GB、CPU: 1.5GHz 以上） • IBM Thread and Monitor Dump Analyzer (TMDA) IBM Thread and Monitor Dump Analyzer（TMDA）は、Java で発生する一般的な問題を解析するツー ルです。WAS で発生するメモリー不足、レスポンス遅延やプロセスダウン時に利用すると、問題を判別 することができます。解析は、WAS の Java スレッド・ダンプ (または javacore ダンプ)で行います。 TMDA は、視覚的なビューを提供しており、個別スレッドの詳細数値を分析できることが特徴です。ま た、Java スレッド・ダンプにデッドロックが存在する場合、TMDA が自動で検出し、報告します。 • IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) は、IBM 冗長ガーベッ ジ・コレクション (GC) トレースを構文解析し、時系列の折れ線グラフを表示することや、Java ヒープ使 用状況を分析し、 Java ヒープ使用状況のパターン・モデルを基にした主要構成を推奨するツールで す。 詳しくは、Information Center の情報を参照してください。 WAS Information Center 「IBM Support Assistant ツールを使用した問題の診断」： http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/a e/ttrb_mdd4j.html 11 4-3-1 JVM 診断ツールのアドオン ここでは、ツールのアドオン方法を説明します。なお、いずれも、ワークベンチのローカル機能として 組み込まれます。リモート操作による診断を行うことはできません。リモート・サーバーを診断する場合 は、診断するデータをワークベンチのクライアントに配置する必要があります。 1). ワークベンチを起動し、メニュー･バーから[更新]→[新規検索]→[ツール・アドオン]をクリックしま す。 2). [新規ツール・アドオンの検索]のウィザードが開始されますので、しばらく待ちます。[インストール するツール･アドオン]が表示されます。アドオンするツールを選択し、[次へ]をクリックします。（本 ガイドの例では MDD4J、TMDA、PMAT をアドオンします） 図 4-11 ツールのアドオン：インストールするツールの選択 12 3). [インストールするアドオンのライセンス]が表示されます。[使用条件の条項に同意します]ボタン をクリックし、[次へ]をクリックします。 図 4-12 ツールのアドオン：ライセンスの確認 4). [要約]が表示されます。内容を確認し、[終了]をクリックすると、アドオンが開始されます。 図 4-13 ツールのアドオン：要約 13 5). [操作の結果]が表示されます。[終了]をクリックすると、ISA Workbanch の再起動を求められます ので、[はい]をクリックします。 図 4-14 ツールのアドオン：アドオン結果 6). ワークベンチのホームから、[問題分析]→[ツール]を選択すると、アドオンされたツールを確認す ることができます。以上で、アドオンは終了です。 図 4-15 ツールのアドオン：ツールの一覧 14 4-3-2 診断ツールによる問題判別 ワークベンチにアドオンした診断ツールを利用し、問題判別を行っていきます。問題判別を行うには、 はじめに、問題の種類を見極めるために必要なデータを収集し、次に、収集したデータを利用して問題 解析を行うことの２段階で行います。 4-3-2-1 Java 用メモリー・ダンプ診断ツール（MDD4J） Java 用メモリー・ダンプ診断ツール（MDD４J）を利用して、メモリー・ダンプ（ヒープ・ダンプ）を解析する 方法を説明します。 1). メモリー・ダンプ（ヒープ・ダンプ）を用意します。すでに解析するファイルがある場合は、手順 2） に進みます。これから取得する場合は、次のステップに従ってください。 • ステップ１：wsadmin スクリプトを起動します。ここでは jython を使用します。 #<WAS_root >/profiles/<dmgr_profile_name>/bin/wsadmin –lang jython 【確認方法】 以下のメッセージが出力され wsadmin コマンドを使用できます。 WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使用し て接続しました。プロセスのタイプは DeploymentManager です。 WASX7029I: ヘルプを表示する場合は、 「$Help help」と入力してください。 wsadmin> • ス テ ッ プ ２ ： JVM bean で generateHeapDump オ ペ レ ー シ ョ ン を 呼 び 出 し ま す 。 JVM objectName の検出 を行います。 #wsadmin> jvm=AdminControl.completeObjectName(‘type=JVM,process=<servername>,*’) #wsadmin>print jvm 例：<process >AMember11 の場合 wsadmin>jvm=AdminControl.completeObjectName(‘type=JVM,process=AMember11,*’) wsadmin> print jvm 【確認方法】 以下のようなメッセージが返されます。 WebSphere:name=JVM,process=AMember11,platform=proxy,node=host1Node01,j2eeType=JVM ,J2EEServer=AMember11,version=7.0.0.0,type=JVM,mbeanIdentifier=JVM,cell=guideCell 01,spec=1.0 15 • ステップ３：メモリー・ダンプを生成します。 #wsadmin> AdminControl invoke (jvm, ‘generateHeapDump’) デ フ ォ ル ト で は 、 以 下 の デ ィ レ ク ト リ ー に 生 成 さ れ ま す 。 WebSphere 環 境 変 数 の [IBM_HEAPDUMPDIR]で出力先を指定することも可能です。 <WAS_root>/profiles/<profile_name> /heapdump.yyyymmdd.ttmmss.pid.phd 2). メモリー・ダンプをワークベンチクライアントのローカルに保管します。 3). ワークベンチを起動し、[問題分析]→[ツール]→[Java 用メモリー・ダンプ診断]を選択し、[起動]ボ タンをクリックします。 図 4-16 ISA Workbench 診断ツール初期画面 4). [ツールの入力パラメーター値]ボックスが起動します。ここでは入力せず[OK]をクリックします。 16 5). Java 用メモリー・ダンプ診断ツールが起動します。[開く]-[新規分析]-[単一ヒープ・ダンプ分析]を 選択し、[プライマリー・ヒープ・ダンプ]に、解析するダンプを指定します。 図 4-17 Java 用メモリー・ダンプ診断 初期画面 6). 診断結果が表示されます。 [サスペクト表示]を選択すると、図 4-18 の画面が表示されます。ここ では、チューニングが必要であると考えられるのデータ構造、オブジェクト・タイプ、パッケージを表 示します。 図 4-18 Java 用メモリー・ダンプ診断ツール：サスペクト表示画面 17 主な項目は以下のとおりです。 データ構造リーク・サスペクト :ヒープ・サイズを増加させる可能性のあるデータ構造をリス ト。 オプジェクト・タイプ・リーク・サスペクト :ヒープ・サイズを増加させる可能性のあるオブジェ クトをリスト。各行は、増加しているデータ構造の先頭にあるオブジェクトのオブジェクト・タ イプを表示。 パッケージ・リーク・サスペクト :ヒープ・サイズを増加させる可能性のあるパッケージをリ スト。 7). [インスタンス表示]を選択すると、以下の画面が表示されます。ここではヒープ・ダンプ内のすべ てのオブジェクトに関する情報をリストしたものです。 [サスペクト表示]に表示されていたオブジェ クトと比較し、[到着サイズ]が大きいクラスを確認することができます。フィルター機能を利用して、 任意のクラス名でリストすることができます。 図 4-19 Java 用メモリー・ダンプ診断ツール：インスタンス表示 18 8). [ツリー表示]を選択すると、以下の画面が表示されます。ここでは、オブジェクト参照の関係ツリー で表示します。 図 4-20 Java 用メモリー・ダンプ診断ツール：ツリー表示 19 4-3-2-2 IBM Thread and Monitor Dump Analyzer (TMDA) IBM Thread and Monitor Dump Analyzer（TMDA）を利用して、Java スレッド・ダンプ（javacore）を解析 する方法を説明します。 1). Java スレッド・ダンプを用意します。解析するダンプファイルがある場合は、手順 2）に進みます。 これから取得する場合は、次のステップに従ってください。 • ステップ１：wsadmin スクリプトを起動します。ここでは jython を使用します。 #<WAS_root >/profiles/<dmgr_profile_name >/bin/wsadmin –lang jython 【確認方法】 以下のメッセージが出力され wsadmin コマンドを使用できます。 WASX7209I: ノード host1CellManager01 のプロセス "dmgr" に、SOAP コネクターを使用し て接続しました。プロセスのタイプは DeploymentManager です。 WASX7029I: ヘルプを表示する場合は、 「$Help help」と入力してください。 wsadmin> • ス テ ッ プ ２ ： JVM bean で generateHeapDump オ ペ レ ー シ ョ ン を 呼 び 出 し ま す 。 JVM objectName の検出 を行います。 #wsadmin>jvm=AdminControl.completeObjectName (‘type=JVM,process=<servername>,*’) #wsadmin>print jvm 例：<process>AMember11 の場合 wsadmin>jvm=AdminControl.completeObjectName(‘type=JVM,process=AMember11,*’) wsadmin>print jvm 【確認方法】 以下のようなメッセージが返されます。 WebSphere:name=JVM,process=AMember11,platform=proxy,node=host1Node01,j2eeType=JVM ,J2EEServer=dmgr,version=7.0.0.0,type=JVM,mbeanIdentifier=JVM,cell=guideCell01,sp ec=1.0 • ステップ３：メモリー・ダンプを生成します。 #wsadmin> AdminControl invoke (jvm, ‘dumpThreads’) 以下のディレクトリーに生成されます。 <WAS_root> /profiles/<profile_name> / javacore.yyyymmdd.hhmmss.pid.txt 2). Java スレッド・ダンプをワークベンチクライアントのローカルに保管します。 3). ワークベンチを起動し、[ツール]→[IBM Thread and Monitor Dump Analyzer]を選択し、クリッ クします。 20 4). [File]→[open Thread Dumps]をクリックします。対象の Java スレッド・ダンプを選択すると、析 サマリーが表示されます。 図 4-21 Java スレッド・ダンプの指定 図 4-22 Thread and Monitor Dump Analyzer のサマリーの表示 主な項目は以下のとおりです。 Thread Method : 処理のメソッド（各メソッドの占める割合を表示） First Dump : 最初のダンプ・ファイル（javacore）が発生した時間 Last Dump : 最後にダンプ・ファイル（javacore）が発生した時間 Garbage Collections per Minute : 1 分あたりのガーベッジ・コレクションの発生回数 Allocation Failures per Minute : 1 分あたりのアロケーション・フェイラーの発生回数 Elapsed Time : 最初のダンプ・ファイル（javacore)と最後のダンプ・ファイル（javacore)が 生成された時間の間隔 Number of hang suspects: ハングしたと思われる回数 21 5). [Analysis]→[Thread Detail]をクリックします。１つずつスレッドの状況を確認することができま す。 図 4-23 Thread Detail による個々のスレッド状況 図 4-24 デッドロックの表示 [State]の項目に表示される主な項目は以下のとおりです。このうち、Blocked、Waiting． Deadlock の発 生比率を確認し、チューニングを検討します。 Runnable： 処理を受付可能な状態 Blocked： 別スレッドが保持しているロックの解放待ち状態 Waiting on condition： sleep()、wait()メソッドや I/O、join()メソッドによる待ち状態 Deadlock：データベース更新等によるデッドロックが発生した状態 6). [Thread Dump List]に表示された 2 つのダンプ・ファイルを選択し、[Analysis]→[Compare Monitors]をクリックします。2 つを比較した結果を確認することができます。同じタスクを実行した 際の違いなどを確認します。赤くなっている箇所はハングする原因の可能性がある箇所です。 図 4-25 ダンプ・ファイルの比較 22 4-3-2-3 IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) ここでは Java Garbage Collector を利用して、ガーベッジ・コレクションの情報を分析する方法を説明し ます。verboseGC データをもとに、ガーベッジ・コレクションの発生頻度、ガーベッジ・コレクションを実行 するのに JVM が費やす時間などを確認する方法を説明します。これらの情報を確認することで、アプリ ケーション稼動時のパフォーマンスを把握することができます。 1). ガーベッジ・コレクションの冗長デバッグ出力を使用し、デバッグ出力をネイティブ・プロセス・ログ に出力されるように設定します。 • ステップ１：管理コンソールを起動し、[サーバー]→[サーバー・タイプ]→[アプリケーション・サーバ ー]→[server_name]とクリックします。次に、[サーバー・インフラストラクチャー]セクションで、 [Java およびプロセス管理]→[プロセス定義]→[Java 仮想マシン]とクリックします。 • ステップ２：[冗長ガーベッジ・コレクション]に、チェックを入れます。[OK]ボタンをクリックし、 [保 存]します。 • ステップ３：WAS プロセスの再起動を行います。その際、<WAS_root>/<profile_name>/log 配 下をリフレッシュしておくと、以後の解析が分かりやすくなります。 2). アプリケーションを実行します。 3). ネイティブ・プロセス・ログ （<WAS_root>/<profile_name>/log/<server_name>/naitive_stderr.log）をワークベンチのクライ アントのローカルに保管します。 4). ワークベンチを起動し、[ツール]→[IBM Pattern Modeling and Analysis Tool for Java Garbage Collector]を選択し、クリックします。 5). [File]→[open verbosegc Filles]をクリックします。対象のネイティブ・プロセス・ログを選択する と、解析サマリーが表示されます。 23 図 4-26 ガーベッジ・コレクター・ツール:解析サマリー 主な項目は以下となります。 Number of Garbage Collections :GC（SYS＋AF）(*1)の発生回数。 Number of Allocation failures : メモリー割り振りに失敗した（Allocation Failure:AF）の 発生回数。また、GC（AF）の回数。JVM ヒープ内に十分に大きな連続領域がなかったた め、GC（AF）が発生したことを示しており、負荷が大きいほど頻繁に発生。 Total Garbage Collection pause :GC を行うために処理を停止した時間の合計[秒]。 Maximum Allocation Request : AF が発生する原因となったヒープ確保の要求の最大 サイズ[bytes]。 Recommendations : 現状で推奨されるチューニング内容を表示。（この内容はあくまで 参考情報ですので、必須事項ではありません。） *1 :ガーベッジ・コレクションのうち、SYS は System Garbage Collection、AF は Allocation Failre を示します。 SYS :System.gc()を呼び出すことで発生する GC です。サーバー自身が、システムの起動 時と終了時に呼び出す処理です。 24 AF :アプリケーションがメモリーを確保する際に、十分なサイズの領域が確保できなかった ため、実施する GC です。 6). [Analysis]→[Graph view all]を選択すると、グラフを出力します。右側に縦に並んでいるボタン から、表示するグラフを選択します。 図 4-27 ガーベッジ・コレクター・ツール：GC のグラフ 主な項目は以下のとおりです。 Used Tenured（After） :GC 後のヒープ使用サイズ(bytes) Used Tenured（Before） :GC 開始時のヒープ使用サイズ（bytes） Requested :AF 発生時のヒープ要求サイズ（bytes） AF Completed :GC(AF)にかかった時間(ms) GC Comleted :GC にかかった時間（ms） 25 7). [Analysis]→[Usage Summery]を選択します。ガーベッジ・コレクションの発生頻度、ガーベッ ジ・コレクション実行の結果、確保したメモリサイズ等を確認することができます。 図 4-28 ガーベッジ・コレクター・ツール：GC 使用サマリー 上記で説明した機能のほかにも、ガーベッジ・コレクションを解析する機能が用意されています。詳しく は、同梱のヘルプ機能を確認してください。 26