Comments
Description
Transcript
3 3-1
3 パフォーマンス管理 ................................................................................................................. 3 3-1 パフォーマンス ...................................................................................................................... 3 3-1-1 パフォーマンスの指標....................................................................................................... 3 3-1-2 スループット ....................................................................................................................... 4 3-1-3 応答時間 ........................................................................................................................... 4 3-2 動的キャッシュ ...................................................................................................................... 5 3-2-1 キャッシュされるコンテンツ ............................................................................................... 5 3-2-2 動的キャッシュ・サービス.................................................................................................. 6 3-2-3 キャッシュのロケーション .................................................................................................. 8 3-2-4 キャッシュ・インスタンス .................................................................................................... 9 3-2-5 キャッシュの複製............................................................................................................. 10 3-2-6 キャッシュの無効化......................................................................................................... 10 3-2-7 ディスク・オフロード ......................................................................................................... 11 3-2-8 cachespec.xml ファイル ................................................................................................. 11 3-2-9 動的キャッシュの設定..................................................................................................... 11 3-2-9-1 動的キャッシュ・サービスの有効化 ............................................................................ 12 3-2-9-2 キャッシュ・インスタンスの作成................................................................................... 13 3-2-9-3 サーブレット・キャッシングの設定 ............................................................................... 14 3-2-9-4 ポートレット・キャッシングの設定 ................................................................................ 15 3-2-9-5 キャッシュ・サイズの設定 ............................................................................................ 15 3-2-9-6 ディスク・オフロードの設定.......................................................................................... 16 3-2-9-7 キャッシュの複製 ......................................................................................................... 20 3-2-9-8 cachespec.xml によるキャッシュ・ポリシーの定義................................................... 22 3-2-9-9 cachespec.xml 記述例 ............................................................................................... 27 3-2-10 動的キャッシュの管理 .................................................................................................. 30 3-2-11 外部キャッシュ............................................................................................................... 35 3-2-11-1 外部キャッシュの設定 ............................................................................................... 35 3-3 チューニング ....................................................................................................................... 40 3-3-1 キューイング・ネットワーク .............................................................................................. 40 3-3-1-1 キューイング・ネットワーク .......................................................................................... 40 3-3-1-2 WAS におけるパラメーター設定 ................................................................................. 45 3-3-2 Web サーバー.................................................................................................................. 48 3-3-2-1 IBM HTTP Server のリクエスト処理方法................................................................... 48 3-3-2-2 IBM HTTP Server のモニタリング .............................................................................. 50 3-3-3 データベース接続............................................................................................................ 52 3-3-3-1 接続プール・サイズ ..................................................................................................... 52 3-3-3-2 Prepared Statement Cache サイズ........................................................................... 52 3-3-4 JVM .................................................................................................................................. 53 3-3-4-1 JVM のチューニング .................................................................................................... 54 3-3-4-2 GC ポリシー.................................................................................................................. 54 3-3-4-3 Optimize for Throughput (-Xgcpolicy:optthruput)................................................... 56 3-3-4-4 Optimize for Pause Time (-Xgcpolicy:optavgpause) ............................................. 58 3-3-4-5 Generational Concurrent (-Xgcpolicy:gencon)....................................................... 59 3-3-4-6 Subpooling (-Xgcpolicy:subpool).............................................................................. 62 3-3-4-7 Java ヒープサイズのチューニング ............................................................................. 62 3-3-4-8 Java ヒープ・サイズの設定.......................................................................................... 67 3-3-4-9 V7.0 での JVM ランタイムの改良点 ........................................................................... 68 3-3-4-10 ランタイム・プロビジョニング ..................................................................................... 68 3-3-4-11 ランタイム・プロビジョニングの有効化...................................................................... 68 3-3-4-12 共有クラスキャッシュ................................................................................................. 69 3-3-4-13 共有クラスキャッシュの設定 ..................................................................................... 70 3-3-4-14 参照の圧縮 (Compressed references)................................................................. 70 3-3-4-15 参照の圧縮の有効化................................................................................................ 70 3-4 モニタリング・ツール ........................................................................................................... 72 3-4-1 Performance Monitoring Infrastructure ....................................................................... 72 3-4-1-1 概要.............................................................................................................................. 72 3-4-1-2 モニターできるデータ................................................................................................... 73 3-4-1-3 PMI 設定....................................................................................................................... 73 3-4-2 Tivoli Performance Viewer ............................................................................................ 75 3-4-2-1 モニターの開始............................................................................................................ 75 3-4-2-2 ユーザー設定およびロギング設定 ............................................................................. 75 3-4-2-3 現行アクティビティの表示（パフォーマンス・モジュール） .......................................... 77 3-4-2-4 モニタリング・ポイント .................................................................................................. 79 3-4-2-5 ロギング ....................................................................................................................... 84 3-4-3 パフォーマンス・アドバイザー ......................................................................................... 86 3-4-4 要求メトリック................................................................................................................... 88 3-4-4-1 基本使用方法 .............................................................................................................. 89 3-4-4-2 トレース・レベルの設定 ............................................................................................... 90 3-4-4-3 フィルターの設定 ......................................................................................................... 91 3-4-4-4 ログの解析................................................................................................................... 92 3-4-5 verbosegc........................................................................................................................ 94 3-4-5-1 verbosegc の設定方法 ............................................................................................... 94 3-4-5-2 verbosegc の出力内容 ............................................................................................... 95 3 パフォーマンス管理 この章では、WAS を使用した Web システムにおいてパフォーマンスを向上させるための考慮点につ いて説明します。 3-1 ではパフォーマンスを計測する際の代表的な指標としてスループットと応答時間について説明し ます。3-2 では、パフォーマンス向上のために WAS で提供されている機能として動的キャッシュについて 説明します。3-3 ではパフォーマンスを向上させるためのパフォーマンス・チューニングを、3-4 ではチュ ーニングを目的としたモニタリングの方法について説明します。チューニング方法については一般論を 紹介しており、各パラメーターの最適値は実際の環境およびアプリケーションによって異なりますのでご 注意下さい。 3-1 パフォーマンス この節では Web システムにおけるパフォーマンスの代表的な指標としてスループットと応答時間（レス ポンスタイム）の２つについての一般的な考え方について説明します。 3-1-1 パフォーマンスの指標 Web システムにおけるパフォーマンスの代表的な指標はスループットと応答時間によって測られま す。以下、それぞれについて説明します。 • スループット：単位時間（秒）あたりにシステムによって処理されるリクエスト数です。ユーザーから のリクエストを一度にどれだけ処理できるかを表す値であり、システム全体の処理能力を表してい ます。 • 応答時間：ユーザーがリクエストを出してから、すべての結果が戻るまでの時間でユーザーから 見た処理能力になります。どれだけスループットが大きくても、各々のユーザーにとって応答時間 が重要な点に注意しなくてはなりません。システムの負荷を判断する指標になり得ます。 システムの性能評価を行う際、横軸を同時ユーザー数、縦軸をスループットとしてプロットしたスループ ットのグラフや、横軸を同時ユーザー数、縦軸を応答時間としてプロットした応答時間のグラフを作成し て分析を行っていきます。 3-1-2 スループット 図 3-1 では Web システムにおいて、同時アクセス数の増加に応じたスループットの変化の典型的な パターンを一例として示しています。アプリケーションやシステムの設定でボトルネックを除去した状態が 前提です。データの推移によって、A ゾーン、Ｂゾーン、Ｃゾーンに分けて、それぞれのゾーンでシステ ムがどのような状態であるかを知ることができます。 図 3-1 スループット • A ゾーン：同時アクセス数の増加に伴い、スループットは増加します。この段階では、システムは すべてのリクエストを滞留させることなく処理できている状態といえます。 • B ゾーン：CPU が 100%に達した後も同時アクセスを増加させると応答時間は悪化しますが、スル ープットは増加します。同時アクセス数がシステムの許容量（飽和点）を超えると、スループットは それ以上伸びなくなり、落ち始めます。 • C ゾーン：飽和点をさらに超えると、スループットは落ち始め、Web システムとしては不健全な状態 となります。これはあまりにもアクセス数が多すぎるため、ネットワーク資源の競合やページング 等が頻発し、本来のシステムの能力が発揮できなくなった状態です。 CPU 使用率が低いにも関わらず、スループットが飽和点に達する場合、システムの能力を活用できて いません。他の要因がボトルネックになっている可能性があるので、ボトルネックを追及して解消する必 要があります。 想定される同時アクセス数に対して、A ゾーンまたは B ゾーンの範囲でシステムが稼動するように、チュ ーニングを行います。 3-1-3 応答時間 図 3-2 では、Web システムにおいて、同時アクセス数の増加に応じた応答時間の変化のパターンを示 しています。 図 3-2 応答時間 一般に、システムに対するリクエスト数が増加すると、システムに余力のある場合は応答時間に大きな 変化はありません。 リクエスト数がシステムの処理能力を超えると応答時間は急速に悪化します。その場合でも、システムが 適切にチューニングされていれば、処理しきれないリクエストはエラーで戻すなどの処理によって、応 答時間は一定の限度内に収めることができます。チューニングが不適切な場合は、いつまで待っても 応答が戻らないような事態も発生し得ます。 想定されるリクエスト数に対して、充分なスループットを持つシステムを設計する必要があると同時に、 要件を満たす応答時間を実現するようにパフォーマンス・チューニングを行う必要があります。 システムの能力を充分に活用し、適切なスループットと応答時間を得るためには、パフォーマンス・チュ ーニングを欠かすことはできません。 3-2 動的キャッシュ Web システムのパフォーマンスを向上させる 1 つの手法にキャッシングがあります。しかし、近年の Web サイトではより質の高いサービスを提供するために、動的なページ生成が主流となり、従来の静的 コンテンツのキャッシュに加えて、動的に生成されるコンテンツをサーバー・サイドでキャッシュすること で、サーバーの負荷を軽減する重要性が増しています。WAS では、V4 以降、動的コンテンツをキャッシ ュする動的キャッシュ機能をサポートしています。この節では、動的キャッシュ機能についての説明、お よびその設定手順について説明します。 3-2-1 キャッシュされるコンテンツ 動的キャッシュ機能をより有効に活用するためには、キャッシュすべきコンテンツの決定や、Web ペー ジのデザインが重要になります。 多くの場合、動的コンテンツのページの中身は、より小さい単位での静的コンテンツやコマンドの実行 結果などのコンポーネントを組み合わせて生成されています。例えば、図 3-3 のような株のポートフォー リオを表示するページを例にとると、ページ全体としては個人ユーザー向けに生成されていても、個々 の銘柄情報に関するデータベースへの問い合わせ結果や、共通のヘッダーやフッターなどをキャッシュ することで、多くのユーザー向けのページを生成する際に再利用することができます。特にデータベー ス・アクセスは非常に負荷が高い処理のため、データベースへの問い合わせ結果をキャッシュすること でパフォーマンスを大幅に向上させることができます。WAS ではサーブレットや JSP の実行結果、コマ ンドの実行結果およびオブジェクト自体をキャッシュすることで、さまざまな粒度でキャッシュを活用する ことが可能です。 キャッシュさせるデータはある程度の有効期間があるものや、有効期間は短くても多くのリクエストに 再利用できるものが最適です。 図 3-3 株のポートフォーリオ・ページ 3-2-2 動的キャッシュ・サービス 動的キャッシュ機能とは、JSP やサーブレットなどの動的コンテンツやコマンドの実行結果を WAS 上に キャッシュする機能です。この機能を利用することで、アプリケーション・サーバーおよびデータベース・ サーバーなどのバックエンド・サーバーの負荷を軽減し、クライアントに対するレスポンス・タイムを短縮 することが可能となります。 動的キャッシュ・サービスは、アプリケーション・サーバーの Java 仮想マシン（JVM）内で動作し、オブ ジェクトの出力を保管したり、キャッシュからそのオブジェクトを提供したりします。キャッシュされたオブジ ェクトはキャッシュ・エントリーと呼ばれ、JVM ヒープに保管されます。また、キャッシュは同一複製ドメイン 内に所属するアプリケーション・サーバー間で共有することが可能です。 WAS V7.0 の動的キャッシュでは、以下のキャッシュをサポートします。 • サーブレット/JSP キャッシュ • コマンド・キャッシュ • オブジェクト・キャッシュ • Web サービス・クライアント・キャッシュ • Web サービス・キャッシュ アプリケーション・サーバー Webサー バー Web ブラウザー キャッシュ キャッシュ Web アプリケーション プロキシー・ サーバー 図 3-4 動的キャッシュ キャッシュ可能なオブジェクトやキャッシュの振る舞いは cachespec.xml ファイルという XML ファイルで 定義され、個々のキャッシュ・エントリーにはキャッシュ ID というユニークな ID が付けられ識別されます。 このキャッシュ ID は cachespec.xml ファイルで定義されたルールに従って生成されるか、もしくは Java コ ーディングを使用して生成することができます。 サーブレット/JSP キャッシュ サーブレットおよび JSP の実行結果を保存します。WAS はサーブレットの service メソッドへの要求を インターセプトし、キャッシュ内のコンテンツに対する要求であればキャッシュからレスポンスを返します。 キャッシュに存在しない場合は、実際に処理を実行し、実行結果をキャッシュします。キャッシュされるコ ンテンツはキャッシュ・エントリーと呼ばれ、サーブレット/JSP キャッシュは、HTTP リクエストのパラメータ ーや属性、URI、セッション情報、Cookie 情報、パス情報、HTTP ヘッダー情報などを元に個々のエント リーとしてキャッシュし、任意のキャッシュ ID を付与して管理することが可能です。 コマンド・キャッシュ コマンド・キャッシュはサーブレット/JSP キャッシュよりもさらに細かい単位でのキャッシュを可能にする もので、コマンド・オブジェクトの実行結果を保存します。例えば、株のオンライン・トレードのページ例 で、ユーザー向けにパーソナライズされた Account Summary と、多くのユーザーにとって共通の情報と なる Market Summary などから構成されます。ユーザーが保持する株の情報などを含む Account Summary はユーザーごとに異なる表示となりますが、Market Summary で表示される各銘柄の情報は 多くのユーザー・リクエスト間で共有可能な情報です。コマンド・キャッシュでは、これらのデータを個々 のユーザー向けの Web ページ生成時ではなく、その前のデータ・アクセスの段階でキャッシュすること で、より高いキャッシュの効果が望めます。 コマンド・キャッシュのコマンドとは、デザイン・パターンの１つであるコマンド・パターンのコマンドを指 します。WAS ではこのコマンド・パターンに基づいたフレームワークとして WebSphere Command Framework という API が提供され、この Command Framework に基づいてアプリケーションを実装するこ とで、コマンド・オブジェクトをキャッシュすることが可能となります。 オブジェクト・キャッシュ WAS V6 から新規にサポートされた機能で、Java オブジェクトのインスタンスをキャッシュに保管し、共 有することができます。オブジェクト・キャッシュでは、ユーザーがアプリケーション・ロジックの中でキャッ シュを利用するロジックを書きます。キャッシュを保管する領域であるキャッシュ・インスタンスを JNDI 名 によりルックアップし、キャッシュ・インスタンスに対して com.ibm.websphere.cache.DistributedMap インタ ーフェースを使用してキャッシュ・エントリーの保管や取出しを行います。コマンド・キャッシュ同様に、デ ータベース・アクセスやビジネス・ロジックの実行結果など生成負荷の高いオブジェクトをキャッシュする ことで、アプリケーション・サーバーやデータベースの負荷を軽減することが可能となります。 Web サービス・クライアント・キャッシュ Web サービス・クライアント・キャッシュでは、Web サービス・クライアントでリモート Web サービスからの応 答をキャッシュします。 Web サービス・キャッシュ Web サービス・キャッシュでは、Web サービス・プロバイダーで Web サービスの応答をキャッシュします。 3-2-3 キャッシュのロケーション キャッシュを活用する際には、前述の何をどの粒度でキャッシュするかといった決定に加えて、どこで キャッシュするかが重要となります。コマンド・キャッシュやオブジェクト・キャッシュはアプリケーション・サ ーバー上の動的キャッシュ・サービスによってキャッシュされますが、サーブレット・キャッシュはアプリケ ーション・サーバー上の他に、外部の Web サーバーやキャッシュ・サーバーにキャッシュさせることが可 能です。外部キャッシュ上ではキャッシュ・エントリーは URI に基づいて管理されます。 一般的に、よりクライアント・サイドに近い外部キャッシュ上でキャッシュされるほうがレスポンス・タイム を向上し、サーバー・サイドの負荷を減らすことが可能ですが、キャッシュするコンテンツによっては、個 人情報や機密情報、認証が必要な情報などを含み、セキュアなロケーションに配置する必要がありま す。そのため、一般的には、ユーザーの固有情報や機密情報などを含むデータは認証サーバーの背 後やセキュアなゾーンにキャッシュします。 図 3-5 は、Web システムを形成する典型的な層構成と、各層でのキャッシュ可能なコンテンツを示し ています。動的キャッシュは、WAS が配置されるプレゼンテーション層やビジネス・ロジック層で使用され ます。その他の層は外部キャッシュとして、下記のコンポーネントにキャッシュを配置可能です。 • • 動的キャッシュ プレゼンテーション層 ビジネス・ロジック層 外部キャッシュ例 Web サーバー・プラグインの ESI キャッシュ WebSphere Proxy Server プロキシー層 Proxy Server 負荷分散 装置 Proxy Server キャッシュ Web サーバー層 プ レゼン テーショ ン層 ビ ジネス・ロ ジック層 IHS Webコンテナー EJBコンテナー プラグイン サーブ レット・ キャッシュ オブ ジェ クト・ キャッシュ オブ ジェ クト・ キャッシュ コマンド・ キャッシュ ESI キャッシュ 外部キャッシュ コマンド・ キャッシュ 図 3-5 キャッシュのロケーション 3-2-4 キャッシュ・インスタンス キャッシュを保持する領域をキャッシュ・インスタンスと呼びます。キャッシュ・インスタンスは動的キャッ シュ・サービスがデータを保管し、取り出し、共有するためのロケーションを提供します。キャッシュ・イン スタンスは複数定義することが可能であり、キャッシュ・インスタンス毎に JNDI 名を定義します。これらの キャッシュ・インスタンスは、独立して存在し、他のキャッシュ・インスタンスの影響を受けません。またキャ ッシュ・インスタンスごとにキャッシュ・サイズやキャッシュ・エントリーの優先順位、ディスク・オフロードの 有無などを設定できます。 アプリケーション・サーバー上で稼動するアプリケーションは、アプリケーション・サーバーが同一複製 ドメインに所属していれば他のアプリケーション・サーバー上のキャッシュ・インスタンスにアクセスするこ とも可能です。WAS V7.0 では 2 つの種類のキャッシュ・インスタンスをサポートします。 サーブレット・キャッシュ・インスタンス サーブレット、JSP、コマンド・オブジェクトおよび SOAP リクエストなどを保持するキャッシュ・インスタン スです。サーブレット・キャッシュ・インスタンスを指定するには動的キャッシュの構成ファイルである cachespec.xml ファイル中の<cache-instance>タグで指定します。キャッシュ・インスタンスを指定しなかっ た場合は、デフォルトで用意されているキャッシュ・インスタンス（JNDI 名 services/cache/basecache）が使 用されます。 オブジェクト・キャッシュ・インスタンス Java オブジェクトを保持、分配、共有するキャッシュ・インスタンスで、以下の API を使用することでア プリケーションがオブジェクト・キャッシュ・インスタンスにアクセスすることが可能です。 • com.ibm.websphere.cache.DistributedObjectCache • com.ibm.websphere.cache.DistrbutedMap ア プ リ ケ ー シ ョ ン は 、 JNDI 名 に よ り キ ャ ッ シ ュ ・ イ ン ス タ ン ス を ル ッ ク ア ッ プ し て 使 用 し ま す 。 DistributedMap および DistributedObjectMap インターフェースは非常にシンプルな API で、これらの API を利用し、アプリケーションは Java オブジェクトへの参照をキャッシュに保管することで Java オブジェ クトをキャッシュし共有することが可能です。 DistributedMap および DistributedObjectCache に関しての詳細は WAS V7.0 Information Center を参 照して下さい。 WAS V7.0 Information Center 「Using the DistributedMap and DistributedObjectCache interfaces for the dynamic cache」 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.d oc/info/ae/ae/tdyn_distmap.html 3-2-5 キャッシュの複製 クラスタリング化されたアプリケーション・サーバー間でキャッシュ・エントリーを共有する機能がキャッ シュの複製機能です。キャッシュ・エントリーを複数のアプリケーション・サーバー間で共有することで、キ ャッシュのヒット率を向上させることが可能です。キャッシュの複製にはデータ・レプリケーション・サービ ス（以下 DRS）が使用されます。キャッシュを共有するアプリケーション・サーバーは同じ複製ドメインに 所属する必要があります。なお、DRS はセッション・オブジェクトの複製にも使用することができますが、 動的キャッシュの複製に使用するドメインとセッション・オブジェクトの複製に使用するドメインは分けるこ とが推奨されます。これは、セッション・オブジェクトの複製と動的キャッシュの複製では、複製先の数が 異なるためです。セッション・オブジェクトは必ずしも全サーバーに複製する必要はありませんが（オリジ ナル以外に最低 1 つ以上存在すればよい）、動的キャッシュはすべてのアプリケーション・サーバーに 複製を配置する必要があるからです。 3-2-6 キャッシュの無効化 キャッシュを使用する上で非常に重要なのは、いつキャッシュを無効化するかです。キャッシュとオリ ジナルのコンテンツやキャッシュの元となるデータベース上などのデータとの一貫性を保持することが大 前提となります。従来の静的コンテンツのキャッシュのようにあらかじめ想定した有効期限を設定する方 式では、データの整合性を厳密に管理できないため、オリジナルのコンテンツやデータ対する変更をトリ ガーに、関連するキャッシュを無効化しキャッシュ・インスタンスから削除する仕組み（キャッシュの無効 化）が必要になります。WAS V7.0 では、以下の方法で動的キャッシュの無効化をサポートします。 • 時間ベース キャッシュが作成されてから指定する秒数を経過することによるエントリーの削除 • グループ・ベース (依存関係 ID による無効化) 作成されたキャッシュを cachespec.xml ファイルを使用して、Dependency ID（依存 ID）規則により グループ化し、任意のタイミングでグループ単位にエントリーを削除 • LRU ルール・ベース キャッシュ・インスタンス内のキャッシュ・エントリーが溢れた際に Least Recently Used（以下 LRU） ルールによる最も使われていないエントリーを削除 • Java コーディング com.ibm.websphere.cache.DistributedMap インターフェースに定義されたメソッドを呼び出すこと による削除 3-2-7 ディスク・オフロード 同時に保存されるキャッシュ・サイズがキャッシュに使用可能なメモリー・サイズより大きい場合には、 ディスク・オフロードの使用を検討します。 キャッシュ・インスタンスは、インスタンス毎に最大キャッシュ・サイズをエントリー数で指定することがで きます（デフォルトは 2000 エントリー）。あらかじめキャッシュ・エントリーに優先度を設定しておくと、この 最大キャッシュ・サイズを超えた場合、キャッシュは優先順位と LRU ルールに従い、メモリーから削除さ れます。しかし、ディスク・オフロード機能を使用すると、メモリーから削除されるキャッシュ・エントリーを ディスク上に退避させておくことが可能となります。ディスクに退避されたキャッシュ・エントリーに対する アクセスが発生すると、そのキャッシュ・エントリーは再びメモリー上にロードされ、別のキャッシュ・エント リーが LRU ルールにしたがってディスクへと退避されます。なお、頻繁にアクセスされるキャッシュ・エン トリーは常にメモリー上においておくために、高い優先順位をつけておくことが推奨されます。 3-2-8 cachespec.xml ファイル 動的キャッシュでのキャッシュ方法に関する動作は、cachespec.xml ファイルによって定義されます。 cachespec.xml では、キャッシュ可能オブジェクトとそのキャッシュ方法を定義します。また、キャッシュ・エ ントリー間の依存関係やタイムアウト、無効化に関してのポリシーもこのファイルで定義します。キャッシュ 可能なオブジェクトは、<cache-entry>エレメントで定義し、各キャッシュ・エントリーに対して、どこにキャッ シュするか(WAS のどのキャッシュ・インスタンス上か、外部キャッシュ上かなど)、どのような情報をもとに キャッシュを区別してキャッシュしていくか（どのようにキャッシュ ID を生成するか）、キャッシュの無効化 をどのようにして行うか（どの依存 ID を使ってキャッシュをグルーピングしグループ単位で無効化する） などを定義します。 cachespec.xml ファイルは、アプリケーション・サーバーの開始時およびファイルが変更されたときに動 的に読み込まれます。動的キャッシュ・サービスは、新しいサーブレットやキャッシュ可能なオブジェクト が初期化されるたびに、この記述を元に、キャッシュを行い、キャッシュ ID を生成します。 cachespec.xml ファイルはアプリケーションのデプロイメント・モジュール内に同梱することも、グローバ ル・レベルでの設定として<WAS_root>/properties ディレクトリーに配置することも可能ですが、アプリケ ーションのメンテナンスを考慮して以下のデプロイメント・モジュール内に配置することが推奨されます。 • モジュール・レベルでの設定 Web モジュールの WEB-INF ディレクトリー EJB モジュールの META-INF ディレクトリー 3-2-9 動的キャッシュの設定 ここでは、動的キャッシュの種類毎に設定方法を説明します。 サーブレット・キャッシュ 1). 動的キャッシュ・サービスの有効化 [3-2-9-1] 2). キャッシュ・インスタンスの作成（オプション） [3-2-9-2] 3). cachespec.xml ファイルによるキャッシュ・ポリシーの定義 [3-2-9-8] 4). 無効化ロジックのアプリケーションへの作りこみ（オプション） WASV7.0 では、ポートレット・キャッシングが追加され、ポートレットが呼び出された際にキャッシュ・エ ントリーを作成することが可能です。ポートレット・キャッシングを使用可能とすると、自動的にサーブレッ ト・キャッシュが使用可能になります。 コマンド・キャッシュ 1). WebSphere Command Framework に基づいたアプリケーションの開発 2). 動的キャッシュ・サービスの有効化 [3-2-9-1] 3). キャッシュ・インスタンスの作成（オプション）[3-2-9-2] 4). cachespec.xml ファイルによるキャッシュ・ポリシーの定義 [3-2-9-8] オブジェクト・キャッシュ 1). DistributedMap インターフェースを用いたアプリケーションの開発 2). 動的キャッシュ・サービスの有効化 [3-2-9-1] 3). キャッシュ・インスタンスの作成（オプション） [3-2-9-2] 以降ではそれぞれのステップでの設定内容を説明します。 3-2-9-1 動的キャッシュ・サービスの有効化 いずれの構成においても、動的キャッシュ・サービスの有効化は必須の作業となります。以下の手順 にしたがって動的キャッシュ・サービスを有効化します。 1). 管 理 コ ン ソ ー ル の ツ リ ー ･ ビ ュ ー 上 で 、 [ サ ー バ ー ] → [ サ ー バ ー ・ タ イ プ ] → [WebSphere Application Server]→[AppServer_name]を選択します。 2). サーバーの管理画面で、[コンテナー設定]→[コンテナー・サービス]下の[動的キャッシュ・サービ ス]を選択します。 サーブレッド・キャッシングを使用可能にする場合には[Web コンテナー設定]を、ポートレット・キャ ッシングを使用可能にする場合には[ポートレット・コンテナー設定]を選択して下さい。 図 3-6 動的キャッシュ・サービスの設定 また、この画面では、キャッシュ・サイズのエントリー数やデフォルト優先順位、およびディスク・オフロ ードの設定が可能です。キャッシュ・サイズに関しては 3-2-9-5、ディスク・オフロードの設定に関しては 3-2-9-6 を参照して下さい。ここで設定した内容はグローバル設定として扱われ、動的キャッシュ・サービ スのデフォルトでの設定値となります。キャッシュ・インスタンス単位や cachespec.xml ファイルで個別に設 定するとその内容で上書することが可能です。なお、動的キャッシュ・サービスに設定された内容は、ア プリケーション・サーバーを再起動するまで有効になりません。 3-2-9-2 キャッシュ・インスタンスの作成 キャッシュ・インスタンスを作成するには、使用したい動的キャッシュに合わせて作成するキャッシュ・イ ンスタンスの種類（オブジェクト・キャッシュ・インスタンス、サーブレット・キャッシュ・インスタンス）を指定し ます。例えば、サーブレット・キャッシュの場合は、管理コンソールのツリー・ビュー上で、[リソース]→[キ ャッシュ・インスタンス]→[サーブレット・キャッシュ・インスタンス]を選択します。 キャッシュ・インスタンスはセル、ノード、クラスター、サーバーの各レベルで設定可能です。設定したレ ベルにより、キャッシュ・インスタンスの JNDI 名の解決に影響がありますので注意して下さい。 図 3-7 は、クラスター・レベルでの設定例になります。 図 3-7 キャッシュ・インスタンス設定の有効範囲 キャッシュ・インスタンスの設定画面では、以下を設定します。 • 名前： キャッシュ・インスタンスの管理用の名前 • JNDI 名： アプリケーションからルックアップする時に使用する JNDI 名 • キャッシュ・サイズ： 最大キャッシュ・エントリー数 その他、このキャッシュ・インスタンス単位でのディスク・オフロード（3-2-9-6 ディスク・オフロードの設定 (p.16)」参照）や複製の設定（「3-2-9-7 キャッシュの複製(p.20）」参照）もこの画面から設定可能です。な お、キャッシュ・インスタンスの作成はオプションで、キャッシュ・インスタンスを明示的に作成しない場合 はデフォルトのキャッシュ・インスタンスが作成され、使用されます。 図 3-8 キャッシュ・インスタンスの設定 3-2-9-3 サーブレット・キャッシングの設定 サーブレット・キャッシングの設定は、サーブレット・キャッシングを有効にしたいアプリケーション・サー バーごとに行います。管理コンソールから[サーバー]→[サーバー・タイプ]→[WebSphere Application Server]→[ApplicationServer_name]→[Web コンテナー設定]→[Web コンテナー]→[サーブレット のキャッシュを使用可能にする]をチェックします。 これらの設定はサーブレット・キャッシングを行うすべてのアプリケーション・サーバーに対して行いま す。また、設定はアプリケーション・サーバーを再起動するまで有効になりません。 図 3-9 サーブレット・キャッシュの設定 3-2-9-4 ポートレット・キャッシングの設定 ポートレット・キャッシングの設定はポートレット・キャッシングを有効にしたいアプリケーション・サーバ ーごとに行います。管理コンソールから[サーバー]→[サーバー・タイプ]→[WebSphere Application Server]→[ApplicationServer_name]→[ポートレット・コンテナー設定]→[ポートレット・コンテナー]→ [ポートレット・フラグメント・キャッシュを使用可能にする]をチェックします。 これらの設定はポートレット・キャッシングを行うすべてのアプリケーション・サーバーに対して行いま す。また、設定はアプリケーション・サーバーを再起動するまで有効になりません。 図 3-10 ポートレット・キャッシングの設定 3-2-9-5 キャッシュ・サイズの設定 WAS の動的キャッシュでは、キャッシュされたオブジェクトを JVM メモリーに保管します。キャッシュに 使用できるメモリーのサイズからキャッシュに保管可能な最大エントリー数を決定し、キャッシュ・サイズに 設定します。キャッシュ・サイズ（デフォルト値：2000）には 100 から 200,000 の整数を指定することができ ますが、キャッシュ自体はメモリー上に保管されるため、キャッシュに使用可能なメモリー領域から、キャ ッシュされる個々のエントリーのサイズを元に適切な最大エントリー数を決定して下さい。また、 WASV7.0 では、キャッシュ・サイズを指定することで、キャッシュによる JVM メモリーの使用量を制限する ことが出来ます。キャッシュ・サイズは、「図 3-6 動的キャッシュ・サービスの設定 (p.12)」の設定画面で デフォルトのキャッシュ・インスタンスに対してキャッシュ・サイズを指定するか、「図 3-8 キャッシュ・イン スタンスの設定 (p.14)」の設定画面で個々のキャッシュ・インスタンスに個別に設定することもできます。 項目 キャッシュ・サイズ メモリー・キャッシュ・ サイズの制限 メモリー・キャッシュ・ サイズ 説明 キャッシュが保持するエントリー数を指定します。 デフォルト値：2000 メモリー・キャッシュ・サイズを使用するか、使用しないかを指定します。 高しきい値 メモリーのキャッシュ・サイズを MB 単位で指定します。 キャッシュ・サイズが高しきい値に達すると、動的キャッシュにより、低しきい値 に下がるまで、サイズを調整します。 デフォルト値：95% 低しきい値 デフォルト値：80% 表 3-1 キャッシュ・サイズの設定 なお、ディスク・オフロードの設定を行うことで、キャッシュ・サイズを超えたエントリーをディスクに退避 させることも可能です。設定手順については、「3-2-9-6 ディスク・オフロードの設定 (p.16)」を参照して 下さい。 3-2-9-6 ディスク・オフロードの設定 ディスクのオフロード機能を使用する場合は、キャッシュ・インスタンスに対して設定を行います。デフォ ルトのキャッシュ・インスタンスを使用する場合は、 [サーバー]→[WebSphere Application Server]→ [ApplicationServer_name]→[コンテナー・サービス]→［動的キャッシュ・サービス] を選択し、「図 3-6 動的キャッシュ・サービスの設定 (p.12)」から下記設定を行います。個々のキャッシュ・インスタンスに対 して設定を行う場合は、[リソース]→[キャッシュ・インスタンス]→[オブジェクト・キャッシュ・インスタンス （またはサーブレット・キャッシュ・インスタンス）]→[<CacheInstance_name>]を選択します。以下、主な 設定項目について、説明します。 項目 ディスク・オフロードを 使用可能にする 説明 ディスク・オフロードの使用可能の有無を設定します。ディスクにオフロードさ れたキャッシュ・エントリーは、再度必要になると、ファイル・システムからメモリ ーに戻されます。 オフロード位置： ディスクへのフラッシュ パフォーマンス設定 メタエントリーごとのキ ャッシュ ID の最大バ ッファー 依存 ID の最大バッ ファー テンプレートの最大バ ッファー ディスク・キャッシュ・ク リーンアップの頻度 削除ポリシー アルゴリズム ディスクに保管されるキャッシュ・エントリーの保管場所を指定します。オフロー ド位置を省略した場合は、下記が使用されます。 <WAS_root>/diskoffload/Node_name/ApplicationServer_name/_dynacache/<C acheJNDI_name> 保管場所を指定した場合は、ノード名、サーバー名およびキャッシュ・インスタ ンス名が自動的に追加されます。例えば、”<WAS_root>/diskoffload” を指定 した場合、実際には下記が使用されます。 <WAS_root>/diskoffload/Node_name/ApplicationServer_name/<CacheJNDI_n ame> この値は、ディスク・オフロードが無効にされている場合は無視されます。 サーバーの停止時に、メモリー内のキャッシュ・オブジェクトをディスクに保管 する場合に選択します。このオプションを選択する場合は、ディスク・オフロー ド機能を使用可能にする必要があります。また、ディスクへのフラッシュ機能を 使用しない場合は、サーバーの停止時にすべてのキャッシュ・オブジェクトが 削除されます。 ・ハイパフォーマンスと高位メモリー使用率 すべてのメタデータをメモリー内に保持します。 ・平衡パフォーマンスと平衡メモリー使用率 メタデータの一部をメモリー内に保持します。 ・ローパフォーマンスと低位メモリー使用率 限られたメタデータをメモリー内に保持します。 ・カスタム 以下の設定項目を指定します。 メタエントリーごとのキャッシュ ID の最大バッファー 依存 ID の最大バッファー テンプレートの最大バッファー ディスク・キャッシュ・クリーンアップの頻度 メモリー内のディスク・キャッシュ・メタデータの、個々の依存 ID またはテンプレ ートに保管されるキャッシュ ID の最大値を指定します。この最大値を超える と、ディスクにオフロードされます。 メモリー内のディスク・キャッシュ・メタデータの依存 ID バケットの最大値を指定 します。この最大値を超えると、ディスクにオフロードされます。 メモリー内のディスク・キャッシュ・メタデータに存在するテンプレート・バケット の最大値を指定します。この最大値を超えると、ディスクにオフロードされま す。 ディスク・キャッシュ・クリーンアップの頻度を分単位で指定します。値を”0”に 設定した場合、クリーンアップは深夜 12 時に実行され、期限切れのキャッシ ュ・エントリーおよび過去 24 時間の間にアクセスされなかったキャッシュ・エント リーを除去します。例えば”60”に設定すると、60 分おきにクリーンアップが実 施されます。また、ディスク・オフロードのパフォーマンス・レベルが「ロー」、「平 衡」、または「カスタム」の場合にのみ適用されます。ハイパフォーマンス・レベ ルでは、ディスクのクリーンアップが必要ではないため、この設定値は無視さ れます。 高しきい値に達した場合にキャッシュ・エントリーを除去する、ディスク・キャッシ ュが使用するアルゴリズムを指定します。 ・なし 高しきい値 低しきい値 動的キャッシュ・サービスがディスクへの書き込みを停止するまで、ディスク・ キャッシュを拡張する可能性があります。 ・ランダム ディスク・サイズが高しきい値に達した場合、ディスク・キャッシュのガーベッ ジ・コレクターが起動し、ディスク上のエントリーをランダムに選択して、サイズ が低しきい値に達するまで除去します。 ・サイズ ディスク・サイズが高しきい値に達した場合、ディスク・キャッシュのガーベッ ジ・コレクターが起動し、ディスク上の最も大きいエントリーを選択し、ディスク・ サイズが低しきい値に達するまで除去します。 除去ポリシーを実行開始するしきい値を、GB 単位、もしくはディスク・サイズに 対するエントリー数のパーセンテージを指定します。 除去ポリシーを実行終了するしきい値を、GB 単位、もしくはディスク・サイズに 対するエントリー数のパーセンテージを指定します。 表 3-2 ディスク・オフロードの設定 図 3-11 ディスク・オフロードの設定 ディスク・オフロードのチューニング ディスク・オフロード機能では、パラメーターを使ったチューニング項目があります。これらのパラメータ ーはカスタム・プロパティーとして設定します。チューニングは、すべてのキャッシュ・インスタンスにわた って設定することもキャッシュ・インスタンス単位で設定することも可能です。 なお、ディスク・オフロードを使用する際には、ディスク書き込みのパフォーマンスを最適化するために ファイル・システムやディスク装置のチューニングも同時に行って下さい。すべてのキャッシュ・インスタン スに対してのカスタム・プロパティーを設定するには以下のステップを実行します。 1). 管 理 コ ン ソ ー ル の ツ リ ー ・ ビ ュ ー 上 の 、 [ サ ー バ ー ] → [ サ ー バ ー ・ タ イ プ ] → [WebSphere Application Server]→[ApplicationServer_name]→[Java およびプロセス管理]→[プロセス 定義]→[Java 仮想マシン]→[カスタム・プロパティー]から[新規作成]ボタンを押します。 2). カスタム・プロパティーの名前を設定します。 3). 設定した名前に対して値を入力します。 4). 構成を保存してアプリケーション・サーバーを再起動します。 サーブレット・キャッシュ・インスタンス単位でカスタム・プロパティーを設定するには以下のステップを 実行します。 1). [ リ ソ ー ス ] → [ キ ャ ッ シ ュ ・ イ ン ス タ ン ス ] → [ サ ー ブ レ ッ ト ・ キ ャ ッ シ ュ ・ イ ン ス タ ン ス ] → [<CacheInstance_name>]→[カスタム・プロパティー]→[新規]ボタンを押します。 2). カスタム・プロパティーの名前を設定します。 3). 設定した名前に対して値を入力します。 4). 構成を保存してアプリケーション・サーバーを再起動します。 オブジェクト・キャッシュ・インスタンスのカスタム・プロパティーを設定するには、[リソース]→[キャッシ ュ・インスタンス]→[オブジェクト・キャッシュ・インスタンス]→[<CacheInstance_name>]→[カスタム・プロ パティー]→[新規]ボタンを押し、同様にカスタム・プロパティーを作成します。ここでは 3 つのカスタム・ プロパティーが設定可能です。 • ディスク・キャッシュのクリーンアップ時間の調整 com.ibm.ws.cache.CacheConfig.htodCleanupFrequency カスタム・プロパティー このプロパティーでは、ディスク・キャッシュのクリーンアップ間の時間を分単位で指定します。 • 遅延オフロード関数の調整 com.ibm.ws.cache.CacheConfig.htodDelayOffloadEntriesLimit com.ibm.ws.cache.CacheConfig.htodDelyOffload 遅延オフロード関数は、依存関係 ID およびテンプレート ID 用に追加のメモリーを使用することで ディスク・オフロードの実行を遅延させ、入出力操作を最小化するかどうかを指定します。 − com.ibm.ws.cache.CacheConfig.htodDelayOffloadEntriesLimit で は 、 依 存 関 係 ID およびテンプレート ID 用バッファーとしてメモリーに保管できるキャッシュ ID の数を 指定します。デフォルトでは”1000”に設定されており、これは各依存関係 ID またはテ ンプレート ID は 1000 の異なるキャッシュ ID までメモリーに保管することができること を意味します。なお、設定できる最小値は”100”になります。 − com.ibm.ws.cache.CacheConfig.htodDelyOffload では追加のメモリー・バッファー を、依存関係 ID およびテンプレート ID 用に使用するかどうかを指定します。デフォ ルトでは”true”(使用可能)に設定されており、この設定によりディスク・オフロードを遅 らせ、ディスクへの入出力操作を最小化します。しかし、ほとんどのキャッシュ ID が 100 バイト以上の場合、この設定を有効にするとメモリーを使いすぎる可能性がありま す。なおこのプロパティーを”false”に設定した場合、すべてのキャッシュ・エントリーは メモリー・キャッシュから除去されると即時にディスクにコピーされます。 3-2-9-7 キャッシュの複製 キャッシュの複製機能では、一度作成されたキャッシュ・データをクラスター内の他のアプリケーショ ン・サーバーに複製します。この機能により、複数アプリケーション・サーバーで同じ要求を実行する実 行時間や実行中に使用するリソースを節約することが可能となります。また、キャッシュの複製は、無効 化機能もサポートしているため、複数アプリケーション・サーバー間でのキャッシュの一貫性を保つことが できます。ここでは、以下の設定手順を説明します。 1). 複製ドメインの作成 2). キャッシュの複製の設定 キャッシュの複製には、データ・レプリケーション・サービスが使用されます。キャッシュの複製を使用 するためには、まずは複製ドメインを作成します。管理コンソールのツリー・ビュー上から、[環境] →[複 製ドメイン] を選択し、複製ドメインの設定画面で[新規作成] ボタンを押します。 図 3-12 では、作成する複製ドメインの名前、要求タイムアウト、暗号化の有無などを設定します。また ここで、レプリカの数は必ず[ドメイン全体]を選択します。これはキャッシュの複製では、クラスター内の 他のアプリケーション・サーバー全てに対して複製を行うためです。 図 3-12 複製ドメインの作成 次にキャッシュの複製の設定を行います。以下の手順で設定します。 3). 管 理 コ ン ソ ー ル の ツ リ ー ・ ビ ュ ー 上 か ら 、 [ サ ー バ ー]→ [ サ ーバ ー・ タ イ プ] → [WebSphere Application Server]から設定したい[ApplicastionServer_name]を選択します。 4). [コンテナー・サービス]→[動的キャッシュ・サービス]を選択します。 5). 図 3-13 で[キャッシュ複製を使用可能にする]をチェックし、[フル・グループ複製ドメイン]には先ほ ど作成した複製ドメインを指定します。 6). 図 3-13 でさらに複製タイプと[push 頻度]を設定します。（詳細は後述します） 7). 上記ステップ 1-4 を、キャッシュの複製を行うすべてのアプリケーション・サーバーに対して行いま す。 8). 設定が終了したら構成を保存します。 図 3-13 キャッシュ複製の設定 なお、キャッシュの複製の設定は、キャッシュ・インスタンス毎に異なる設定を行うこともできます。キャ ッシュ・インスタンス単位で設定する場合は、使用しているキャッシュ・インスタンスの一般プロパティー画 面から同様の設定を行います。 複製タイプの設定 [複製タイプの設定]には以下のモードが設定可能です。 • push と pull の両方 キャッシュは必要に応じてコピーされます。アプリケーション・サーバーは、キャッシュ・エントリーを 作成すると、複製ドメイン内の他のアプリケーション・サーバーに新しく更新されたコンテンツのキ ャッシュ ID を送ります。各アプリケーション・サーバーはクライアントからの要求を受け取ると、そ の要求に対するキャッシュ ID が存在するかをあらかじめ把握しているため、キャッシュ・コンテン ツを保持するサーバーからコンテンツを受け取るか、存在しない場合は自身で要求を処理して新 しいキャッシュ ID を生成します。 • push のみ この複製タイプの設定は推奨されていませんので、ご注意下さい。必要に応じて、このオブジェク トに対するキャッシュ・エントリーを、複数のアプリケーション・サーバー間で共用します。アプリケ ーション・サーバーが、このオブジェクトのキャッシュを確認できなかった場合、他のアプリケーショ ン・サーバーに確認します。どのアプリケーション・サーバーでも、このオブジェクトのキャッシュさ れたコピーを確認できない場合、オリジナルのアプリケーション・サーバーがリクエストを実行しオ ブジェクトを生成します。 • push のみ キャッシュ ID およびそのコンテンツは、自動的に複製ドメイン内のすべてのアプリケーション・サー バーに複製されます。したがって、全てのアプリケーション・サーバー内にキャッシュ・エントリーの 複製が常に置かれることになります。 • 共有しない キャッシュおよびキャッシュ ID は、アプリケーション・サーバー間で共有されません。 push 頻度 [push 頻度]には、新しいキャッシュ・エントリーや更新されたエントリーを他のサーバーに送信する頻 度を秒で指定します。”0”に設定された場合、キャッシュ・エントリーは即座に送信されます。”0”より大き い値を設定すると、その間に作成または変更された全てのキャッシュ・エントリーがバッチ的に送信され ます。ただし、キャッシュの無効化はここで設定した秒数とは別に即座に実行されます。 cachespec.xml によるキャッシュ・ポリシーの定義 前項で設定したキャッシュ複製の設定は、cachespec.xml ファイルで設定した内容で上書きすることが できます。cachespec.xml ファイルの各エントリーには<sharing-policy>エレメントを使用してキャッシュ複 製の設定を行うことができます。これにより、個々のエントリー単位でキャッシュ複製の設定を変更するこ とが可能です。<sharing-policy>の値には 4 つのタイプが指定できます。詳細は「3-2-9-8 cachespec.xml によるキャッシュ・ポリシーの定義」を参照して下さい。なお、<sharing-policy>が設定されていないエント リーに対しては、グローバル設定が適用されます。 3-2-9-8 cachespec.xml によるキャッシュ・ポリシーの定義 動的キャッシュ・サービスでは、キャッシュ・ポリシーを構成ファイル cachespec.xml で定義します。 cachespec.xml では、キャッシュ可能オブジェクトとそのキャッシュ方法を定義します。何をキャッシュする かを<cache-entry>エレメントを使って定義し、各キャッシュ・エントリーに対して、どこにキャッシュするか (WAS のどのキャッシュ・インスタンス上か、外部キャッシュ上かなど)、どのような情報をもとにキャッシュ を区別してキャッシュしていくか（キャッシュ ID の生成ルール）、キャッシュの無効化をどのようにして行う か（依存関係 ID によるグルーピングのルール）などを定義します。 <cache-entry>エレメントは、<cache>または<cache-instance>エレメント内で定義します。<cache>エレメ ント内の<cache-entry>は、デフォルトのキャッシュ・インスタンスにキャッシュされます。<cache-instance> エレメント内の<cache-entry>は、<cache-instance>エレメントの<name>属性で指定されているキャッシュ・ インスタンスにキャッシュされます。 以下、cachespec.xml ファイルによるポリシー定義の作成手順を説明します。 1). cachespec.xml ファイルを作成します。 <WAS_root>/properties ディレクトリーの cachespec.sample.xml ファイルを、Web モジュールの WEB-INF ディレクトリーまたは EJB モジュールの META-INF ディレクトリーに cachespec.xml フ ァイルとして配置します。 2). キャッシュ可能オブジェクトの識別に必要な<cache-entry>エレメントを定義します。エレメント内 の記述方法に関しては Cachespec.xml ファイルの記述（p.23）」を参照して下さい。 3). キャッシュ ID の生成ルールを作成します。詳細については Cachespec.xml ファイルの記述（p. 23）」を参照して下さい。 4). (オプション)依存関係 ID ルールを指定します。 <dependency-id>エレメントを使用してキャッシュ・グループ ID を指定します。この ID は、複数の キャッシュ・エントリーを同じグループ ID に関連つけます。 5). （オプション）無効化 ID 生成ルールを指定します。 無効化 ID は、依存関係 ID と同じ方法で定義されます。 6). cachespec.xml ファイルを保管します。動的キャッシュ・サービスは更新済みファイルを自動的に 再ロードしますが、古いポリシー・ファイルによってキャッシュに保管されたオブジェクトは、ファイ ルの更新によって無効化はされません。これらのオブジェクトは新規ポリシーにより再利用される か、あるいは置換アルゴリズムによってキャッシュから除去されます。 Cachespec.xml ファイルの記述 ここでは、cachexpec.xml ファイルの中から主要なエレメントについて説明します。全エレメントの詳細 については、InfoCenter を参照して下さい。 WAS V7.0 Information Center 「cachespec.xml file」 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.d oc/info/ae/ae/rdyn_cachespec.html <cache> cachespec.xml ファイルのルート・エレメントで、<cache-instance>および<cache-entry>エレメントを含み ます。 <cache-instance> <cache-instance name=“CacheInstance_name”></cache-instance> 明示的にキャッシュ・インスタンスを指定した場合に、name 属性にキャッシュ・インスタンスの JNDI 名 を定義します。キャッシュ・インスタンスの JNDI 名は、管理コンソールまたは wsadmin を使ってキャッシ ュ・インスタンス作成/編集時に設定します。 <cache-entry> キャッシュ・エントリーを記述します。キャッシュ・エントリーごとに動的キャッシュがそのエントリーを操 作する際に必要な基本情報を定義します。ここで、<cache>タグ内に指定された<cache-entry>はデフォ ルトのキャッシュ・インスタンスに、<cache-instance>タグ内に指定された<cache-entry>は指定のキャッシ ュ・インスタンス内にキャッシュされます。 <cache-entry>エレメントは class、name、sharing-policy、skip-cache、property および cache-id エレメント を含むことができます。 <class> <class> command | servlet | webservice | JAXRPCClient | static | portlet</class> <class>は必須のエレメントで、キャッシュ対象のオブジェクトの種類を指定します。Command クラスは コマンド・キャッシュ、Servlet クラスはサーブレット/JSP のキャッシュ、webservice クラスは Web サービス要 求、JAXRPCClient クラスは Web サービス・クライアントのキャッシュ・エントリーを定義する際に使用され ます。また、static は静的コンテンツ、portlet はポートレット・キャッシュを指定します。 定義例： <class>command</class> <name> <name>name</name> キャッシュするオブジェクトを指定します。 • サーブレット/JSP キャッシュおよび静的ファイルの場合 cachespec.xml ファイルが Web モジュール内に配置される場合、コンテキスト・ルートからの相対 パスで指定します。 定義例： <name> mywebApp/myjsp.jsp </name> ファイルがアプリケーション・サーバーの properties ディレクトリーに配置されている場合は、フ ル・パスで指定する必要があります。 • コマンド・キャッシュの場合 キャッシュ対象オブジェクトのフル・クラス名（.class まで含む）を指定します。 定義例； <name> com.mycompany.MyCommand.class </name> <sharing-policy> <sharing-policy> </sharing-policy> not-shared | shared-push | shared-pull | shared-push-pull 3-2-9-73-2-9-7 キ ャ ッ シ ュ の 複 製 (p. 20) 」 で 設 定 し た キ ャ ッ シ ュ 複 製 の グ ロ ー バ ル 設 定 は 、 cachespec.xml ファイルを使って個々のキャッシュ・エントリーごとに上書き設定することができます。 cachespec.xml ファイルの各エントリーには<sharing-policy>エレメントを使用してキャッシュ複製の設定を 行うことができます。<sharing-policy>の値には以下の 4 つのタイプが指定でき、クラスター構成において キャッシュの複製に関するポリシーを指定します。デフォルト値は”not-shared”で、また<sharing-policy> エレメントが記述されていない時にもこの値が適用されます。スタンドアロン・サーバー環境で は、”not-shared”のみが有効です。 ポリシー Not-shared サーバー間 での連携 × メモリーの利 用効率 － Shared-push ○ △ Shared-pull ○ ○ Shared-pushpull ○ ○ 動作 キャッシュが生成されたアプリケーション・サーバーのみ でキャッシュを保持し共有はされない。デフォルト値。特 定ユーザーが複数回使用するキャッシュに使用。 キャッシュのエントリーが生成されると他のアプリケーシ ョン・サーバーにエントリーとキャッシュ ID を自動的に配 布。常に各サーバー上にキャッシュのコピーが作成され る。耐障害性は高いがすべてのサーバーにキャッシュ が配置されるのでリソースを多く使用する。多くのユー ザーに使われ、かつヒット率も高いキャッシュに使用。 アプリケーション・サーバーは自身のキャッシュにオブジ ェクトが存在しない場合、他のアプリケーション・サーバ ーに照会してキャッシュが存在するかを調べる。どのサ ーバーにもキャッシュが存在しない場合は自分で処理 を行う。 キャッシュが作成されるとキャッシュ ID のみを他のアプリ ケーション・サーバーに配布。これにより、アプリケーショ ン・サーバーは特定のキャッシュ ID に対するエントリー をどのアプリケーション・サーバーにとりに行けばよい か、または自分で処理を実施すべきかを判断できる。 表 3-3 キャッシュ複製タイプ <property> <property name=”key”>value</property> 動的キャッシュのオプション構成の設定を行います。ここで Key はこのキャッシュ・エントリー・エレメン トのプロパティー名で、value にその値を指定します。主な構成情報を下記に記述します。 • edgeCacheable EdgeSideInclude キャッシュの可否を指定します。サーブレット/JSP キャッシュを使用している際 に、”true”または”false”を設定することができます。デフォルトは”false”です。”true”に設定されて いると、EdgeSideInclude キャッシュが可能になります。 • externalCache 外部キャッシュ名を指定します。外部キャッシュ名は外部キャッシュ・グループ名と一致する必要 があります。 • persist-to-disk キャッシュのディスクへの書き込み可否を指定します。デフォルトは”true”です。”false”に設定され ている場合、キャッシュ・エントリーはディスクに書き込まれません。 <cache-id> キャッシュ・エントリーに付与されるキャッシュ ID を生成する方法を指定します。この ID は、ユーザー 作成のカスタム Java コードか、各キャッシュ・エントリーに定義されたキャッシュ・ポリシーのルールから生 成されます。各キャッシュ・エントリーには複数のキャッシュ ID 生成ルールを定義することが可能で、ル ールは有効なキャッシュ ID が生成されるか、実行するルールがなくなるまで実行されます。 また、いずれのルールも有効なキャッシュ ID を生成できなかった場合は、そのオブジェクトはキャッシ ュされません。 <cache-id>では、オブジェクトをキャッシュするためのルールを定義します。<cache-id>エレメントは timeout、inactivity、priority、property、idgenerator、metadatagenerator サブエレメントで構成されます。 <cache-id>component | timeout | inacitivity | priority | property | idgenerator | metadatagenerator</cache-id> 主な構成情報を下記に記述します。 • <component> キャッシュ ID の生成に使用される情報を指定します。component サブエレメントは属性の id、 type、ignore-value および index、method、field、required、value および not-value エレメントな どから構成されます。 id 属性を使用してコンポーネントを識別し、type 属性を使用してコンポーネントの種類を識別しま す。type 属性の値には、サーブレット・キャッシュの場合 parameter、cookie、session、header、 requestType などが指定可能です。コマンド・キャッシュの場合、method、field が指定可能です。 Web サ ー ビ ス ・ ク ラ イ ア ン ト ・ キ ャ ッ シ ュ の 場 合 、 SOAPEnvelope 、 SOAPHeaderEntry 、 operation 、 part 、 が 指 定 可 能 で す 。 Web サ ー ビ ス ・ キ ャ ッ シ ュ の 場 合 、 SOAPEnvelope 、 SOAPAction、serviceOperation、serviceOperationPrameter が指定可能です。required エレメ ントが、true に設定されると、キャッシュ ID 生成にはこの<component>で定義したルールが非ヌ ル値を戻さなければいけないことを示します。詳細については、InfoCenter を参照して下さい。 • <timeout> <timeout>value</timeout> キャッシュ・エントリーの存続時間を絶対時間を秒数で設定します。0 または負の値を設定する と、キャッシュ・エントリーは無限に保持されます。 • <inactivity> <inactivity>value</inactivity> キャッシュ・エントリーがアクセスされた最終時刻からの、キャッシュ・エントリーの存続時間を指定 するために使用します。最終キャッシュ・ヒットから数えてキャッシュを保持する秒数を指定しま す。 • <priority> <priority>value</priority> キャッシュ・エントリーの優先順位を指定します。キャッシュが最大キャッシュ・サイズに到達する と、LRU に基づきキャッシュ・エントリーがメモリーから除去またはディスクにオフロードされる際に 使用されます。Value には 1 から 255 の整数が設定可能です。 • <idgenerator>および<metadatagenerator> <idgenerator>classname</idgenerator> <metadatagenerator>classname</metadatagenerator> これらのサブエレメントは com.ibm.websphere.servlet.cache.IdGenerator 、 com.ibm.websphere.cache.webservices.IdGenerator com.ibm.websphere.servlet.cache.metaDataGenerator com.ibm.websphere.cache.webservices.MetaDataGenerator インターフェースを実装したカス タム・クラスを用いて、独自ロジックによるキャッシュ ID の生成を行う際に使用します。classname にクラス名を指定します。 <dependency-id> 複数のキャッシュ・エントリーをグループ化し、グループを識別する際に使用される依存関係 ID を生 成するルールを定義します。依存関係 ID は依存関係 ID 基本ストリング（キャッシュ・グループ名）と component エレメントの値を用いて生成されます。component エレメントの指定方法は cache-id と同じで す。 定義例 <dependency-id>CompanyCache <component id=“company” type=“parameter”> <required>true</required></component> </dependency-id> <invalidation > キャッシュを無効化する際に、無効化するキャッシュを識別するために使用される無効化 ID を生成し ます。依存関係 ID と無効化 ID とが一致した場合、該当する依存関係 ID を持つキャッシュ・エントリー は全て無効化されます。指定方法は<cache-id>や<dependency-id>と同じです。 3-2-9-9 cachespec.xml 記述例 「3-2-9-8cachespec.xml によるキャッシュ・ポリシーの定義 (p. 22)」で説明した cachespec.xml の記述 例を紹介します。例としてここでは Trade アプリケーションを使用します。Trade アプリケーションとは WAS の ベ ン チ マ ー ク 用 ア プ リ ケ ー シ ョ ン で 、 以 下 の サ イ ト か ら 入 手 可 能 で す 。 http://www-306.ibm.com/software/webservers/appserv/was/performance.html Trade アプリケーションの中で Trade6 アプリケーションは、動的キャッシュ・サービスを利用しています。 以下の Web モジュールの WEB-INF ディレクトリーに Trade6 用 cachespec.xml ファイルがあります。 <WAS_root>/profiles/<DM_profile>/config/cells/<cell_name>/applications/Trade.ear/deployments/Trade /tradeWeb.war/WEB-INF ここではこの cachespec.xml ファイルの一部を紹介します。Trade アプリケーションの内容についての詳 細は、Trade アプリケーションに含まれるドキュメントを参照して下さい。また、その他のベンチマーク用ア プリケーションとして、DayTrader アプリケーションがあり、以下のサイトから入手可能です。 http://geronimo.apache.org/ サーブレット・キャッシュの定義 「例 3-1 サーブレット・キャッシュ・エントリー定義例」は、home サーブレットに対するキャッシュ・エントリ ーの定義です。home サーブレットはユーザーが指定した処理を実行し、結果を返すサーブレットです。 このキャッシュ・エントリーはサーブレットのキャッシュ・エントリーのため、<class>エレメントで”servlet”を、 name エレメントで”home”サーブレットの URI である”/app”を指定します。<cache-id>以下はこのキャッシ ュ・エントリーに対するキャッシュ ID を生成する際使用されるルールを定義しています。action パラメータ ーが home（URI が/app?action=home）で、サーブレット・エンジンが有効な JSESSIONID Cookie の値を 取れる時のみキャッシュされ、キャッシュ ID には、URI と JSESSIONID Cookie の値が使用されます。つ まり、/app?action=home の結果はユーザーごとに異なるキャッシュ・エントリーとして保持されます。 ま た home サ ー ブ レ ッ ト に は 、 Account_UserID と Holdings_UserID と い う 2 つ の 依 存 関 係 ID<dependency-id>が定義されています。これらは、HTTP セッションの uidBean の値をグループ名として グルーピングされるように定義されています。 <cache-entry> <class>servlet</class> <name>/app</name> <cache-id> <component id="action" type="parameter"> <value>home</value> <required>true</required> </component> <component id="JSESSIONID" type="cookie"> <required>true</required> </component> <property name="EdgeCacheable">true</property> </cache-id> <dependency-id>Account_UserID <component id="action" type="parameter" ignore-value="true"> <value>home</value> <required>true</required> </component> <component id="uidBean" type="session"> <required>true</required> </component> </dependency-id> <dependency-id>Holdings_UserID <component id="action" type="parameter" ignore-value="true"> <value>home</value> <required>true</required> </component> <component id="uidBean" type="session"> <required>true</required> </component> </dependency-id> </cache-entry> 例 3-1 サーブレット・キャッシュ・エントリー定義例 コマンド・キャッシュの定義 例 3-2 コ マ ン ド ・ キ ャ ッ シ ュ ・ エ ン ト リ ー の 定 義 例 」 は コ マ ン ド ・ キ ャ ッ シ ュ を 定 義 し て い ま す 。 AccountCommand は、ユーザーのアカウント情報を取得するオブジェクトで、getUserID メソッドの戻り値 をキャッシュ ID としてキャッシュされます。このキャッシュ・エントリーも依存関係 ID のルールから、 Account_UserID グループに属していることがわかります。 <cache-entry> <class>command</class> <sharing-policy>not-shared</sharing-policy> <name>com.ibm.websphere.samples.trade.command.AccountCommand</name> <cache-id> <component type="method" id="getUserID"> <required>true</required> </component> <priority>3</priority> </cache-id> <dependency-id>Account_UserID <component id="getUserID" type="method"> <required>true</required> </component> </dependency-id> <dependency-id>AllUsers </dependency-id> </cache-entry> 例 3-2 コマンド・キャッシュ・エントリーの定義例 無効化の定義 例 3-3 無効化の定義例」は、無効化のポリシーを定義しています。OrderCompletedCommand には 無効化 ID <invalidation>として Account_UserID と Holdings_UserID が定義されています。これにより、 OrderCompletedCommand が実行されると、AccountUserID または Holdings_UserID と合致するグルー プ名（依存関係 ID）でグルーピングされているキャッシュ（つまりこのコマンドを実行したユーザー名に関 するキャッシュ）は無効化されます。 <cache-entry> <class>command</class> <sharing-policy>not-shared</sharing-policy> <name>com.ibm.websphere.samples.trade.command.OrderCompletedCommand</name> <invalidation>Account_UserID <component id="getUserID" type="method"> <required>true</required> </component> </invalidation> <invalidation>Holdings_UserID <component id="getUserID" type="method"> <required>true</required> </component> </invalidation> (省略) </cache-entry> 例 3-3 無効化の定義例 3-2-10 動的キャッシュの管理 Dynamic Cache Monitor とは、キャッシュの統計、キャッシュ・エントリーやキャッシュ・ポリシーに関する 情 報 を 表 示 す る ア プ リ ケ ー シ ョ ン で 、 CacheMonitor.ear フ ァ イ ル と し て 提 供 さ れ て い ま す 。 CacheMonitor.ear ファイルは、<WAS_root>/installableApps 下に配置されており、これをインストールす ることで、以下の項目を確認することができます。 • 動的キャッシュの構成の検査 • キャッシュ・ポリシーの検査 • キャッシュ統計のモニター • ディスクにオフロードされたデータの表示 • キャッシュ内のデータの管理 • キャッシュからのエントリー除去 • 特定の依存関係 ID に対するすべてのエントリー除去 • 特定のテンプレートに対するすべてのエントリー除去 • 最低使用頻度キューの先頭へのエントリー移動(エントリー除去を回避する) • ディスクからキャッシュ・インスタンス内のメモリーへのエントリーの移動 • キャッシュ・コンテンツ全体の消去 • ESI プロセッサー上のコンテンツを消去ディスク・キャッシュのコンテンツ消去 以降では、Dynamic Cache Monitor のインストール手順を示します。なおセキュリティーを考慮して、 通常のアプリケーションとは異なるホスト名とポート番号を使用するため、最初に仮想ホストを別途作成 します。 仮想ホストの作成 1). 管理コンソールのツリー・ビュー上から、[環境]→[仮想ホスト]を選択し[新規作成]ボタンを押しま す。 2). 名前に仮想ホストの名前（ここでは”cache_monitor”を指定）を設定し、[適用]ボタンを押します。 3). 追加プロパティーの[ホスト別名]→[新規作成]ボタンを押し、ホスト名に”*”（アスタリスク）、ポート に任意のポート番号（キャッシュ管理の目的に使用するポート番号。ここでは”9070”を使用）を設 定し、[OK]ボタンを押し、構成を保存します。 図 3-14 仮想ホストの作成 4). 次にアプリケーション・サーバーの Web コンテナーの Inbound Chain を作成します。管理コンソー ルのツリー・ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSphere Application Server] →[ApplicationServer_name]→[Web コンテナー設定]→[Web コンテナー・トランスポート・チェ ーン]を選択し、[新規作成]ボタンを押します。 5). トランスポート・チェーン名に任意の名前（ここでは”CacheMonitor”を指定）を設定し、[次へ]ボタ ンを押します。 6). ポート名には任意の名前（ここでは”9070”を使用）、ホストには”*”（アスタリスク）、ポートには 3) で設定したポート番号（”9070”）を設定し[次へ]ボタンを押します。 図 3-15 トランスポート・チェーンの作成 7). 設定した内容を確認して[終了]ボタンを押し、構成を保存します。 8). 上記ステップ 4)6)を Dynamic Cache Monitor を導入する全てのアプリケーション・サーバーに対 して実施します。このとき、同一ノード上で複数のアプリケーション・サーバーを稼動している場合 はポート番号が重複しないように注意して下さい。また、1)3)で設定した以外のポート番号を使用 する場合は、都度仮想ホストの追加設定をして下さい。 Cache Monitor のインストール 次に Cache Monitor アプリケーションを監視対象サーバーに導入します。 1). 管理コンソールのツリー・ビュー上から、[アプリケーション]→[エンタープライズ・アプリケーション] →[インストール] を選択します。 2). アプリケーション・インストールの準備画面で、CacheMonitor.ear ファイルへのパスを設定し、[次 へ]をクリックします。（デフォルトでは、<WAS_root>/installableApps の下にあります。） 3). 次の画面では、[詳細]、[デフォルト・バインディングの生成]、[Web モジュールおよび SIP モジュ ールにデフォルト仮想ホスト名を使用する:]を選択し、[ホスト名]に先ほど作成した仮想ホストを指 定します。 図 3-16 仮想ホストの指定 4). 次のセキュリティーに関する警告ページでは[継続]をクリックします。 5). [ステップ 1]ではデフォルトのまま[次へ]をクリックします。 6). [ステップ 2]では[クラスターおよびサーバー]からアプリケーションをインストールするクラスターま たはサーバーを選択し、[Dynamic Cache Monitor]モジュールを選択して[適用]ボタンをクリッ クします。 図 3-17 導入先サーバーの設定 7). [ステップ 6]では [Dynamic Cache Monitor]WebModule をチェックし、仮想ホストには先ほど作 成した[cache_monitor]を選択します。 図 3-18 Web モジュールへの仮想ホストのマップ 8). [ステップ 9]で内容を確認し、[終了]を実行し、[マスター構成に保管]を実行します。 9). アプリケーション・サーバーを再始動します。 10). Cache Monitor にアクセスするには、下記 URL を利用します。 http://<Host_name＞:<Port_number>/cachemonitor ここで<Host_name>には Cache Monitor アプリケーションをインストールしたサーバーのアドレ ス、<Port_number>には、Cache Monitor 用に定義したポート番号（ここでは 9070）を指定しま す。なお、WebSphere セキュリティーが設定されている場合は、有効なユーザーID とパスワー ドが必要になります。 キャッシュ・モニターにアクセスすると、図 3-19 のようなページが表示されます。ここからキャッシュに 関する統計を表示したり、キャッシュ内容(図 3-20 キャッシュ内容)を表示したり、キャッシュを操作する ことが可能です。 図 3-19 キャッシュ・モニター画面 図 3-20 キャッシュ内容 3-2-11 外部キャッシュ 動的キャッシュには、サーブレット・キャッシュを WAS の外部に配置し、制御する機能があります。より クライアントに近い場所でキャッシュ・ヒットさせることにより、レスポンスが返されるまでのホップ数が減り 応答時間も向上しますし、バックエンドのシステムにかかる負荷を軽減することにもつながります。外部キ ャッシュの配置先としては、以下の 3 つがサポートされます。なお、二つ目の FRCA キャッシュは V7.0 よ り、三つ目の Edge Components の Caching Proxy は V6.1 より非推奨になりましたので、ご注意下さい。 • Web サーバー・プラグインの ESI プロセッサー • IBM HTTP Server の高速応答キャッシュ・アクセラレーター（FRCA キャッシュ） • Edge Components の Caching Proxy 3-2-11-1 外部キャッシュの設定 外部キャッシュを行うには、外部キャッシュ・グループを作成してキャッシュの配置先などを指定し、キ ャッシュ・エントリーごとのキャッシュの可否などを定義します。外部キャッシュを行うために必要な定義は 以下の通りです。 1). 外部キャッシュ・グループ定義の作成 2). 外部キャッシュ・グループ・メンバーの定義 3). Cachespec.xml ファイルでの定義 4). 各コンポーネントでの定義 以降ではステップ 1)、2)、3）および 4）に関して、ESI キャッシュの設定方法を説明します。 外部キャッシュ・グループとメンバーの定義 外部キャッシュ・グループは以下の手順で作成します。 1). 管 理 コ ン ソ ー ル の ツ リ ー ・ ビ ュ ー 上 か ら 、 [ サ ー バ ー]→ [ サ ーバ ー・ タ イ プ] → [WebSphere Application Server]を選択し、設定を行うアプリケーション・サーバーをリストから選択します。 2). 構成パネルで[コンテナー・サービス]→[動的キャッシュ・サービス]を選択し、追加プロパティーの [外部キャッシュ・グループ]を選択します。 3). [新規作成]で外部キャッシュ・グループの名前を入力し、[OK]ボタンを押し、構成を保存します。な お、デフォルトで ESI キャッシュ用の外部キャッシュ・グループ（EsiInvalidator）が存在しますの で、そのまま利用して下さい。 図 3-21 外部キャッシュ・グループの作成 次に外部キャッシュ・グループのメンバーを定義します。 4). 管 理 コ ン ソ ー ル の ツ リ ー ・ ビ ュ ー 上 か ら 、 [ サ ー バ ー]→ [ サ ーバ ー・ タ イ プ] → [WebSphere Application Server]→[ApplicationServer_name]→[コンテナー・サービス]→[動的キャッシ ュ・サービス]から、先ほど作成した外部キャッシュ・グループを選択します。 5). [外部キャッシュ・グループ・メンバー]→[新規作成]を選択します。 6). アドレスには、アダプターBean が外部キャッシュに接続する際に使用するアドレス、アダプター Bean 名には使用する Bean 名を定義します。使用する外部キャッシュに応じて表 3-4 外部キャ ッシュ・タイプと定義するアダプター名およびアドレス」に従って定義して下さい。 図 3-22 外部キャッシュ・メンバー定義 7). [OK]ボタンを押し、構成を保存します。 外部キャッシュ・グループ・メンバーの追加時には、使用する外部キャッシュに応じて下記の表に従っ て定義して下さい。 外部キャッシュ アダプター名 アドレス ESI com.ibm.websphere.servlet.cache.ESIInvalidatorServlet ホスト名(：ポート) FRCA com.ibm.ws.cache.servlet.Afpa ポート番号 Caching com.ibm.websphere.edge.dynacache.WteAdapter ホスト名：ポート番号 Proxy 表 3-4 外部キャッシュ・タイプと定義するアダプター名およびアドレス Cachespec.xml ファイルでの定義 外部キャッシュにキャッシュさせるためのポリシーを定義します。cachespec.xml ファイルで各キャッシュ・ エントリーに以下を追加定義します。 • ESI キャッシュ <property name="EdgeCacheable">true</property> 定義例： <cache-entry> <class>servlet</class> <name>/marketSummary.jsp</name> <property name="EdgeCacheable">true</property> <cache-id> <priority>3</priority> <timeout>180</timeout> </cache-id> <dependency-id>MarketSummary </dependency-id> </cache-entry> 例 3-4 cachespec.xml ファイル定義例 Edge Side Include キャッシュの設定 Edge Side Include とは、フラグメント化された Web ページを動的に統合しページを生成するためのマー クアップ言語を規定したオープン・スタンダードな仕様で、Web サーバー・プラグインには、Edge Side Include (以下 ESI)プロセッサーが組み込まれています。ESI プロセッサーは Web サーバー・プラグイン のメモリー上に動的コンテンツのフラグメントをキャッシュします。 Web サーバー・プラグインが受け取った要求は、ESI プロセッサーに送信（ESI プロセッサーが有効で あることが前提）され、キャッシュの有無がチェックされます。そこでキャッシュ・ミスが発生すると、 Surrogate-Capability ヘッダーが追加され、その要求がアプリケーション・サーバーに転送されます。アプ リケーション・サーバーはサーブレット・キャッシュが使用可能になっており、かつ応答が外部キャッシュ 可能である場合、Web サーバー・プラグインへの応答として Surrogate-Control ヘッダーを戻します。 Surrogate-Control 応答ヘッダーの値にはルールのリストがあり、ESI プロセッサーはこれを使用してキャ ッシュ ID を生成し、ESI キャッシュ内にキャッシュを保管します。 ESI キャッシュを使用するには、WAS 上に DynaCacheESI.ear をインストールして下さい。また、 plugin-cfg.xml ファイルで ESI キャッシュの有効/無効（デフォルトでは有効になっている）と最大キャッシ ュ・サイズおよび ESI キャッシュへの無効化通知に関する下記設定を行います。 • ESI プロセッサーの有効化 <Property Name="ESIEnable" Value="true" /> 無効化の場合は”false”を設定します。False に設定された場合、その他の設定は無視されます。 • キャッシュ最大サイズの指定 <Property Name="ESIMaxCacheSize" Value="1024" /> キャッシュの最大サイズ(K バイト単位)を指定します。デフォルトは１M バイトです。なお、キャッシ ュが満杯になると、もっとも有効期限に近いエントリーから削除されます。 • 無効化通知の設定 <Property Name="ESIInvalidationMonitor" Value="false" /> ESI プロセッサーがアプリケーション・サーバーからの無効化通知を受けるかどうかを指定しま す。無効化通知を受けるためには、ESIInvalidationMonitor の値を”true”に設定します。なおこの 機能を使用するためには、DynaCacheEsi アプリケーションをアプリケーション・サーバーにイン ストールする必要があります。 また、WebSphere プロキシー・サーバーでも ESI プロセッサーによる動的コンテンツをキャッシュさせる 設定が可能です。管理コンソールのツリー･ビュー上で、[サーバー]→[サーバー・タイプ]→ [WebSphere プロキシー・サーバー]→[ProxyServer_name]→[プロキシー設定]→[HTTP プロキシー・ サーバー設定]→[プロキシー設定]を選択し、[動的コンテンツのキャッシング]をチェックし、動的キャッ シュ・サービスを設定します。ここでは、DynaCacheEsi アプリケーションをインストールする必要はありま せん。 図 3-23 プロキシー・サーバーの動的キャッシュ・サービスの設定 ESI キャッシュを設定し、WebSphere プロキシー・サーバーにて動的コンテンツがキャッシュされた場 合には cache.log が更新され、初回リクエスト時や有効期限が切れた動的コンテンツの場合には proxy.log が更新されます。 3-3 チューニング この節では、パフォーマンスを向上させるためのパラメーター・チューニングについて説明します。 WAS でチューニングを考慮する際の基本的なポイントはキューイング・ネットワークと JVM メモリーのチ ューニングになります。キューイング・ネットワークのチューニングでは WAS だけではなく Web サーバー も考慮する必要があります。Web サーバーのチューニングについては 3-3-2Web サーバー(p.48)で説明 します。 3-3-1 キューイング・ネットワーク キューイング・ネットワークの考え方とチューニングで設定する WAS の各コンポーネントのパラメータ ーについて説明します。 3-3-1-1 キューイング・ネットワーク Web アプリケーションにおいては、クライアントからのリクエストはランダムにサーバーに到達し、サー バーが一度に受け取るリクエスト数は非常に波があるのが通常です。また、システムには許容量があり、 ある程度を超えたリクエストを同時に処理しようとすると、システム本来の性能が発揮できない可能性が あります。このため、WAS ではリクエストが Web サーバー、アプリケーション・サーバー、データベースを 流れる際に、各々のコンポーネントの入り口で一度に処理するリクエストの数を制限します。処理しきれ ない分は行列に並ばせ、順番に受け付けます。このときの待ち行列を「キュー」と呼び、待ち行列による リクエスト管理を「キューイング」と呼びます。サーバーは、一定限度までのリクエストは並行に処理します が、システムに設定された数を超えた同時リクエストは、キューに入れられ、処理の順番を待ちます。 同時リクエスト数が非常に多く、キューの中での待機時間が長くなって、キューへの送信側で設定さ れたタイムアウト値を超えた場合は、クライアントにエラーとして戻されます。システムの許容量を超えたリ クエストがあった場合に、ユーザーのストレスを軽減し、システムの負荷を必要以上に大きくしないため には適切なタイムアウトの設定も重要です。 キューには、オープン・キューとクローズド・キューの２種類があります。 • オープン・キュー キューの中で活動状態にあるリクエスト数に制限はありません。 • クローズド・キュー キューの中で活動状態にあるリクエスト数に上限があり、システムによってリソースへの同時アク セスが管理されています。クローズド・キューの中のリクエストは、活動状態か待ち状態のいずれ かの状態となります。活動状態とは、このリクエストが対象のコンポーネントによって現在実行中 であるか、更に先のコンポーネントによる処理の終了待ち状態である場合をいいます。待ち状態 とは、このリクエストが対象のコンポーネントによる実行待ちである場合をいいます。 アプリケーション・サーバーに対するサーブレットの実行要求は複数のコンポーネントによって順番に 処理が行われていきます。以下の図に一連の処理の例を示します。ブラウザーからのリクエストはネット ワークを経由して、Web サーバーで受け付けられます。Web サーバーの処理を経て、WAS のコンポー ネントである Web コンテナーと EJB コンテナーで処理され、データ・ソースを使用したデータベース接続 の処理が行われます。Web サーバー、Web コンテナー、EJB コンテナー、データ・ソースの各コンポーネ ントにはそれぞれキューが存在し、この一連のキューのつながりをキューイング・ネットワークと呼びま す。各々のキューはクローズド・キューであり、同時に実行可能なリクエスト数に制限があります。 図 3-24 キューイング・ネットワーク • Web サーバーのキュー • Web コンテナーのキュー（オープン・キューとしても構成可能） • EJB コンテナーのキュー（オープン・キューとしても構成可能） • データ・ソースのキュー パラメーター調整の原則 キューの中で活動状態にあるリクエスト（スレッド）の最大数を各コンポーネントのパラメーターで設定す ることが可能です。 同時に実行可能なスレッド数を増やすことによって、ある程度はスループットの向上が望めますが、その 数はコンポーネントが稼動するマシンの能力に依存するものです。過剰なスレッドの実行はメモリーなど のリソースを必要以上に消費し、パフォーマンスの低下を招くことになります。 それぞれのパラメーターを調整して、各コンポーネントで過剰なスレッドが実行されることのない最適値 を見い出します。 各コンポーネントの一連の処理が、シームレスに処理される環境であれば各コンポーネントで設定す るパラメーターは同じ数になりますが、実際は各コンポーネントで処理可能なスレッド数は異なり、キュー で待ちが発生することになります。 一般的には、ネットワーク側（Web サーバーの手前）で処理を待つリクエストの数を多く、アプリケーシ ョン・サーバー内部で処理を待つリクエストの数が小さくなるように調整します。リクエストの待機は、その コンポーネントへの負荷が発生するので、リクエストをできるだけネットワーク側で待たせることによってア プリケーション・サーバーへの負荷を軽減することができます。ネットワーク側でリクエストを待機させるこ とができない場合は、アプリケーション・サーバー側で待機させることになります。 また、バックエンド側のスレッド数を増やしたい場合は、その前段のコンポーネントのスレッド数も増加 させて多くのリクエストを受け付けるようにする必要があります。 図 3-25 にパラメーター調整の一例を示します。クライアントから同時に到着した要求数 200 に対し、 Web サーバーへの接続待ちが 125、Web コンテナーの接続待ち、データベース（データ・ソース）への接 続待ちがそれぞれ 25 となっています。 図 3-25 パラメーター調整 理想的には、システムの負荷テストを行った上で、それぞれのキューの最大数に達したときにシステム の CPU の使用率が 100%となり、システムの最大のパフォーマンスが得られるように、パラメーターを設 定するのが良いでしょう。 アプリケーションの構成によっても、キューのパラメーターを調整する必要があります。具体的には以 下の例があてはまります。 • ほとんどのページが静的コンテンツ（HTML ファイルなど）で構成され、クライアントからの要求のう ちサーブレットの実行を必要とするものが少ないサイトの場合、HTTP サーバーのキューのサイズ を特に大きくする必要があります。 • サーブレット内部での複雑な処理に CPU の 90%、データベース接続を使用した簡単な処理に残 りの 10%を使用しているアプリケーションの場合、平均すれば同時実行中のサーブレットのうち 10%のみがデータベースに同時に接続していることになります。この場合、データ・ソースのキュ ーのサイズは、Web コンテナーのキューのサイズよりはるかに小さくて済みます。 • 逆に、処理のほとんどがデータベースに接続した状態で行われるサーブレットでは、Web コンテナ ーのキューのサイズと、データ・ソースのキューのサイズはほとんど同じとなります。 トランスポート・チャネル WAS V7.0 でも V6 から導入されたチャネルフレームワークが採用されています。 WAS V5.x では、図 3-26 WAS V5 における Web サーバー－HTTP トランスポート間の接続にあるよ うに Web サーバー経由のリクエストはデフォルトで KeepAlive 接続となるため、一度 Web サーバーのプ ラグインが WAS の HTTP トランスポートに対して生成した接続は切断されることなく次回のアクセスの際 に再利用されました。これによって、接続の生成・切断にかかる時間と負荷を軽減することができました が、一方ではクライアントと Web コンテナーのスレッドが直接結びつくことで、特定のクライアントに Web コンテナーのスレッドが占有されるという状態がありました。 図 3-26 WAS V5 における Web サーバー－HTTP トランスポート間の接続 WAS V7.0 では、図 3-27 にあるように TCP トランスポート・チャネルがクライアントからのリクエストを受 け付け、Web コンテナーのスレッドで使用可能状態であるスレッドにリクエストを割り当てていきます。 Web サーバーと Web コンテナー間が直接 KeepAlive 接続にならず間に TCP トランスポート・チャネルを 介することで、特定のクライアントが Web コンテナーのスレッドを占有するということがなくなりました。 Web コンテナーのスレッドは１クライアントのレスポンスを返した時点で、キューに入っているリクエスト の処理を実行することができ、より有効にスレッドが使用されます。 図 3-27 WAS V7.0 における Web サーバー－トランスポート・チャネル間の接続 負荷分散時のキューイング・ネットワーク 負荷分散装置を使用して、リクエストを複数のサーバーに分散して実行する場合は、以下の点に注 意が必要です。 • セッション・アフィニティなどの使用により、複数のサーバーに必ずしも均等に要求が振り分けられ るとは限りません。偏る可能性がある場合は、各サーバーで同時に受け付ける要求数を多めに 設定することが必要な可能性もあります。 • いったん分散された要求が合流するような箇所がある場合（DB サーバーが 1 台の場合など）はそ の部分がボトルネックにならないよう、サーバーのサイジングやパラメーターの設定に十分に注意 します。 図 3-28 負荷分散時のキューイング・ネットワーク 3-3-1-2 WAS におけるパラメーター設定 システムを構成するキューのパラメーター、特にクローズド・キューにおける要求の最大同時実行数を 調整することは、システムのスループットを向上させるうえで重要です。これらには以下のパラメーターが 挙げられます。 Web サーバー IBM HTTP Server（以下、IHS）の場合、パラメーターの設定は、<IHS_root>/conf/httpd.conf ファイル で行います。IHS の最大同時実行数はファイル中の MaxClients/ThreadsPerChild ディレクティブで設定 します。設定値を超えた要求に対するタイムアウトは、Web ブラウザーごとの実装によって決定されま す。IHS は v1.3 と v2.0/6.0 ではリクエストの処理方法が異なり、リクエストに対する親プロセス、子プロセ スの振る舞いが異なります。3-3-2-1IBM HTTP Server のリクエスト処理方法(p.48)]を参照して下さい。 Web コンテナー Web コンテナーの最大同時実行数は、アプリケーション・サーバーの Web コンテナー・スレッドのパラ メーターで設定します。管理コンソールより、以下の手順で設定画面を表示します。 ① [サーバー] → [ サ ー バ ー ・ タ イ プ ] → [WebSphere Application Server] → [ApplicationServer_name] → [コンテナー設定] → [Web コンテナー設定] → [Web コン テナー] を選択し、対象のアプリケーション・サーバーの、Web コンテナーの設定画面を表示し ます。 ② Web コンテナーの設定画面から、[追加プロパティー]→[Web コンテナー・トランスポート・チェ ーン]→[WCInboundDefault]→[TCP インバウンド・チャネル(TCP 2)]→[関連項目]→[スレッ ド・プール]→[WebContainer]と選択して、スレッド・プールの設定画面を表示します。 図 3-29 Web コンテナースレッド・プール プール内のスレッドは、[最大サイズ]で設定した値まで、作成可能です。プール内で使用されていな いスレッドは、[スレッド非活動タイムアウト]経過後に[最小サイズ]に設定したスレッド数まで破棄されま す。 パラメーターの変更後は[適用]または[OK]ボタンを押下して、保管作業を行いアプリケーション・サーバ ーの再始動が必要となります。 TCP トランスポート・チャネル TCP トランスポート・チャネルで受け付ける接続の最大値は TCP インバウンド・チャネルで設定しま す。管理コンソールより以下の手順で設定画面を表示します。 ① [サーバー] → [ サ ー バ ー ・ タ イ プ ] → [WebSphere Application Server] → [ApplicationServer_name] → [コンテナー設定] → [Web コンテナー設定] → [Web コン テナー・トランスポート・チェーン] を選択し、対象のアプリケーション・サーバーの、トランスポー ト・チェーンの設定画面を表示します。 ② トランスポート・チェーンの設定画面から、[WCInboundDefault] → [TCP インバウンド・チャ ネル(TCP 2)] を選択し、TCP インバウンド・チャネルの設定画面を表示します。 図 3-30 TCP トランスポート・チャネル [最大のオープン接続数]で設定した数だけの接続を受け付けます。[非活動タイムアウト]ではリクエス トがない状態で KeepAlive 接続が切断されるまでのタイムアウト値を設定します。 EJB コンテナー EJB に対するメソッド呼び出しは、図 3-25 パラメーター調整に示されるように、EJB クライアントが EJB の稼動している EJB コンテナー上ではなく、リモート・クライアントからの場合に限って、キューを介し て行われます。 別プロセス内で動作する EJB クライアントからの EJB 呼び出しは、RMI/IIOP プロトコルによって行わ れ、EJB コンテナー側の ORB によって処理されます。ここでは、ORB スレッド・プールが EJB コンテナー のキューとしての役割を果たします。 ただし、ORB スレッド・プールは要求到着時に空きスレッドがない場合は、新規のスレッドを作成して 要求を実行し、このスレッドの実行が終了するとスレッドを破棄します。同時に実行されるスレッドの数に 上限が無いため、EJB コンテナーのキューはオープン・キューとなります。 EJB コンテナーのスレッド・プール・サイズは、こういったキューおよびアプリケーションの特徴を踏まえて 決定する必要があります。 管理コンソールより、[サーバー] → [サーバー・タイプ] →[WebSphere Application Server] → [ApplicationServer_name] → [コンテナー設定] → [コンテナー・サービス] → [ORB サービス] → [追加プロパティー] → [スレッド・プール設定] → [スレッド・プール設定] を選択して、スレッド・プール の設定画面を表示します。 図 3-31 ORB スレッド・プール プール内のスレッドは、[最大サイズ]で設定した値まで、作成可能です。プール内で使用されていな いスレッドは、[スレッド非活動タイムアウト]経過後に[最小サイズ]に設定したスレッド数まで破棄されま す。 パラメーターの変更後は[適用]または[OK]ボタンを押下して、保管作業を行いアプリケーション・サー バーの再始動が必要となります。 データ・ソース データ・ソースの最大同時実行数は、各データ・ソースの接続プールのパラメーターで設定します。 管理コンソールより、[リソース] → [JDBC] → [JDBC プロバイダー] → [JDBCProvider_name] → [追加プロパティー] → [データ・ソース] → [DataSource_name] → [追加プロパティー] → [接続プー ル・プロパティー]を選択して、接続プールの設定画面を表示します。 図 3-32 接続プール 最大同時実行数は、最大接続数で設定します。 3-3-2 Web サーバー 3-3-2-1 IBM HTTP Server のリクエスト処理方法 Unix 環境ではリクエストの処理方法が IBM HTTP Server（以下、IHS） V1.3 と V2.0 以降 (V2.0 / 6.0 / 6.1 / 7.0) で異なります。Windows 環境のリクエスト処理方法は全バージョン共通です。(WAS V7.0 で は、IHS V6.1 以降をサポートしています。) • IBM HTTP Server v1.3 の処理方法 IHS V1.3 の起動により生成された親プロセスは、子プロセスを生成して IHS に来るリクエストを処理さ せます。同時に処理可能なリクエストの数は子プロセスの数に依存します。生成する子プロセスの数は httpd.conf ファイルで設定可能です。最大同時実行数は MaxClients で決定され、指定された数は生成 される最大子プロセス数になります。 親プロセス リクエスト毎に プロセス生成・消去 子プロセス 子プロセス 子プロセス 図 3-33 IHS V1.3 のリクエスト処理（UNIX 系） • IBM HTTP Server V2.0 以降での処理方法（UNIX 系） IHS V2.0 以降ではリクエストを子プロセスで処理させるのではなく、各々の子プロセスがスレッドを生 成し、そのスレッドによってリクエストが処理されます。IHS で同時に処理できるリクエスト数は httpd.conf ファイルで設定する MaxClients で決定されますが、指定された数はリクエストを実行するスレッドの最大 数を示しています。 子プロセスが生成する各スレッドがリクエストを実行することによって、V1.3 よりも少ない子プロセス数 で多くのリクエストを実行することができます。子プロセス数の減少によって、子プロセスの生成にかかる 負荷を抑制できることができます。 親プロセス リクエスト毎に スレッド生成・消去 子プロセス スレッド スレッド スレッド 子プロセス スレッド スレッド スレッド 図 3-34 IHS V2.0 以降のリクエスト処理（UNIX 系） • Windows 環境での IBM HTTP Server (全バージョン共通) の処理方法 Windows 環境では、生成された親プロセスによって、１つの子プロセスが生成されます。子プロセスが スレッドを生成し、そのスレッドによってリクエストが処理されます。最大同時実行数は ThreadsPerChild で決定され、指定された数は生成される最大スレッド数を示しています。 図 3-35 Windows 環境のリクエスト処理（Windows） IHS7.0 のスレッド生成に関するディレクティブは以下になります。( )内は AIX 環境でのデフォルト値にな ります。 • MaxCliens(600)：サービスを行うスレッド合計数の上限 • ThreadsPerChild(25)：各子プロセスが生成できるスレッド数 • ThreadLimit(25)：ThreadsPerChild に設定可能な上限値 • MaxSpareThreads(75)：待機状態のスレッドの数の上限 • MinSpareThreads(25)：待機状態のスレッド数の下限 • StartServers(1)：サーバー起動時に作成される子プロセスの数 • MaxRequestsPerChild(0)：１つの子プロセスが処理できるリクエストの最大数 • ServerLimit(64)：親プロセスが生成可能な子プロセスの上限 3-3-2-2 IBM HTTP Server のモニタリング IBM HTTP Server（以下、IHS）の mod_status モジュールを利用することによって Server status ページ から、IHS のプロセスがリクエストを処理する状況をモニターすることができます。 設定手順 以下に、設定手順を示します。 ① IHS の構成ファイル（<IHS_root>/conf/httpd.conf）を開き、以下のように status_module と server-status の Location タグのコメント・アウト（#）が外れていることを確認します。 LoadModule status_module modules/mod_status.so <IfModule mod_status.c> ExtendedStatus On </IfModule> …省略… <IfModule mod_status.c> <Location /server-status> SetHandler server-status Order deny,allow Deny from all # Add an "Allow from" directive to provide access to the server status page. …省略… # Allow from 192.168.1 </Location> </IfModule> 「Allow from」に続くドメイン名を指定することによって、Server status ページへのアクセスを制限 することができます。指定したドメイン名のマシンからのみアクセスが可能になります。必要に応じ て指定します。 ② ③ 構成ファイルの変更を保管して、IHS を再起動します。 Web ブラウザーで「http://<host_name>/server-status」にアクセスして Server status ページ を表示します。URL を「http://<hostname>/server-status?refresh=5」と指定することによって、 5 秒間隔で更新します。 図 3-36 Server status ページ 3-3-3 データベース接続 データ・ソースを使用してデータベースへの接続を行う際のパフォーマンス上の考慮点について説明 します。 3-3-3-1 接続プール・サイズ データベースへの接続を作成する処理は、非常に負荷のかかる処理となるため、WAS では作成した 接続をプールして再利用するという仕組みになっています。プールすることができる接続の最大数はデ ータ・ソースのパラメーターの最大接続数で設定します。 3-3-3-2 Prepared Statement Cache サイズ JDBC は動的な SQL のインターフェースなので、「SQL 発行→SQL 文のプリコンパイル（プリペア処 理）→実行」というプロセスが、たとえ同じ SQL が発行されたとしてもリクエストがある度に毎回繰り返され ます。データベースにとって、プリペア処理は負荷が大きい処理なので、プリペア処理を省くことでパフ ォーマンスの向上が望めます。 そこで、一度行われたデータベースのプリペア処理を再利用して、負荷を軽減するのが Prepared Statement Cache の機能になります。データベース・アクセスをするアプリケーションは Prepared Statement を利用してコーディングし、WAS でステートメント・キャッシュを利用すると、データベース側でプリペア処 理が行われた SQL が WAS にキャッシュされ、効率的にプリペア処理を省略することができます。 ステートメント・キャッシュは接続プールのコネクションごとにキャッシュされるため、以下のように設定 することが推奨されています。 推奨値＝異なる PreparedStatement の SQL の総数 実行される SQL 文は内容が同じでも、大文字・小文字が異なると異なるステートメントとして扱われるの で注意が必要です。 ステートメント・キャッシュ・サイズはデータ・ソースの一般プロパティーで設定します。管理コンソール のナビゲーション・ツリーより[リソース]→[JDBC]→[JDBC プロバイダー]→[JDBCProvider_name]→[追 加 プ ロ パ テ ィ ー ] → [ デ ー タ ・ ソ ー ス ] → [DataSource_name] → [ 追 加 プ ロ パ テ ィ ー ] → [WebSphere Application Server データ・ソース・プロパティ]を選択して、WebSphere Application Server データ・ソ ース・プロパティのページを表示します。[ステートメント・キャッシュ・サイズ]フィールドで、１コネクション あたりのステートメント・キャッシュの数を指定します。 図 3-37 WebSphere Application Server データ・ソース・プロパティ ステートメント・キャッシュ・サイズは、Tivoli Performance Viewer で廃棄されるステートメント・キャッシュ をモニターして調整することができます。ステートメント・キャッシュ数が設定した値を超えると、キャッシュ は廃棄されていきます。廃棄が確認された場合はその数だけステートメント・キャッシュ・サイズを増加さ せるとよいでしょう。3-4-2-4 モニタリング・ポイントの 6)データ・ソース接続プール」を参照して下さい。 3-3-4 JVM JVM とは、Java 仮想マシン(Java Virtual Machine : JVM)のことで、Java バイトコードをそのプラットフォ ームのネイティブコードに変換して実行するソフトウェアです。Java 言語で開発されたソフトウェアは、配 布時にプラットフォームから独立した独自の形式（Java バイトコード）になっており、そのままでは実行す ることができません。このため、そのプラットフォーム固有の形式（ネイティブコード）に変換するソフトウェ アを用意して、変換しながら実行します。この変換と実行を行うのが JVM です。 3-3-4-1 JVM のチューニング Java アプリケーションの実行環境である JVM が使用する仮想ストレージは一般にヒープと呼ばれてい ます。WAS V7.0 の使用している JVM は IBM Developer Kit For Java 5.0 から採用された J9 VM と呼ば れる JVM です(以後、特に断りのない限り、JVM とは WAS に搭載されている Java 仮想マシンを指し示 すものとします)。また、JVM のサブコンポーネントでヒープの状態管理(メモリ管理)を担当しているのは ST コンポーネントと言います。 商品表示、決済処理、機器制御など、Java アプリケーションとして世の中に出ているソフトウェアには 目的に応じた様々な機能が実装されており、それゆえヒープには様々なタイミングで様々なオブジェクト の割り当て要求が発生します。このように多種多様に使用される状況では、単一のメモリー管理ポリシー の運用ではすべての使用ケースで均一のパフォーマンスを出すことができません。メモリー管理ポリシ ーとはヒープ管理のアルゴリズムを規定するもので、GC ポリシーとも呼ばれます。JVM がデフォルトで採 用している GC ポリシーによって幅広い種類のアプリケーションで最適なパフォーマンスが出ると言われ ています。ただし、今挙げた理由によりケースによってはデフォルトの GC ポリシーでは最適なパフォー マンスが出せない場合があります。そのため JVM では複数のメモリー管理ポリシーが提供され、必要に 応じて適切なポリシーを選択できるようになっています。 一般に JVM のチューニングではポイントが二つあります。まず適切なメモリー管理ポリシーの選択を 行なう必要があります。その上で、次にシステムに合ったヒープサイズの設定を行います。この節ではま ず最適な GC ポリシーを選択するために個々の GC ポリシーの仕組みについて説明を行っていきます。 ポリシーを理解したうえでパフォーマンス要件を満たすために最適な GC ポリシーを選択するための指 針を示します。最後に GC ポリシー別に分けてヒープサイズのチューニング方法を解説していきます。 3-3-4-2 GC ポリシー Java プログラムの大きな特徴のひとつに JVM によるヒープ管理があります。C 言語のようにプログラマ が明示的にヒープの確保と開放を行うのではなく、それらの作業を JVM に委譲することでより安全なプ ログラムの作成が行えるようになっています。JVM(具体的には JVM の ST コンポーネント)が提供するメ モリー管理方法は GC ポリシーを指定することで変更することができます。ヒープにはアプリケーションに よって使用されるすべてのオブジェクトが格納されますが、この割り当てと使用後の整理を行うのがメモリ ー管理の主な役割です。 アプリケーションの内部で new 演算子が使用されてオブジェクトの初期化が指示されると、JVM はヒ ープへのオブジェクト割り当て作業(ヒープ･アロケーション：Heap allocation)を行います。この作業は JVM がオブジェクトの使用するメモリー領域をヒープ内に確保し、アプリケーションがその領域を使える ように参照情報を渡します。この参照情報を取得することで、アプリケーション・スレッドはオブジェクトを 実際に使用することができるようになります。ST コンポーネントはヒープ内のどこにオブジェクトが存在す るかを管理するのではなく、ヒープ内のどこに空き領域が存在するかを管理しています。個々の空き領 域はひとつのリストによって数珠繋ぎに管理されており、ヒープ･アロケーション実施時にはリストの中から オブジェクトを格納可能な空き領域の検索が行われます。一般にこのヒープ内の空き領域を管理するリ ストを Free list と呼んでいます。 Free list にオブジェクトを格納できるサイズの空き領域がない場合、割り当て失敗(Allocation Failure)と なります。Allocation Failure の発生が使用していないオブジェクト(ガーベッジ)をヒープから廃棄する作 業、すなわちガーベッジ･コレクションのトリガーとなります。「ガーベッジとなった」オブジェクトとは、アプ リケーションから参照されなくなったオブジェクトのことです。同じ観点からヒープ内の「生きた」オブジェ クトは、スレッドのスタックや static なフィールドから直接参照しているオブジェクト（Root オブジェクトと呼 ばれています）、および Root オブジェクトやその子オブジェクトなどが参照していて Root オブジェクトか ら到達可能になっているオブジェクトと定義できます。「ガーベッジとなった」オブジェクトと「生きた」オブ ジェクトの大まかなイメージ図を以下に示します。 到達可能な(「生きた」)オブジェクト ( はRootオブジェクト ) 到達不可能なオブジェクト (ガーベッジ) Sweep対象 図 3-38 「生きている」オブジェクトとガーベッジ ヒープ･アロケーションおよびガーベッジ･コレクションのアルゴリズムについてはこれまで沢山の研究 が行われてきており、多種多様な手法がこれまで生み出されています。WAS V7.0 で使用されている J9 VM では以下にあげる 4 つの GC ポリシーが利用可能となっています。下記表には GC ポリシーの選択 の目安も記載していますが、あくまでも目安ですので実際にはパフォーマンス・テストを実施し最適な GC ポリシーを決定します。ただ、これまでの実績では、デフォルト GC ポリシーである Optimize for Throughput が最適であるケースが多いです。 GC ポリシー 選択の目安 Optimize for Throughput アプリケーションのスループットを重視する場合(デフォルト・ポリシー) Optimize for Pause Time アプリケーションのレスポンスを重視し、GC による停止時間を抑える場合 Generational Concurrent アプリケーションが生成するオブジェクトの生存期間が短い場合 Subpooling アプリケーションが多量のスレッドを使用し（16CPU 以上の SMP 環境）、多 くのオブジェクトをアロケーションする場合 表 3-5 GC ポリシーとその特徴 この 4 つの GC ポリシー共通で言えるのですが、どのポリシーでもヒープ内のオブジェクト管理方法と して、ガーベッジがどこにあるのかを管理するのではなく、「生きている」オブジェクトがどこにあるのかを 管理しています。「生きている」オブジェクトが使用していない領域に存在しているオブジェクトをガーベ ッジと判断して、その領域のメモリーを開放しています。 それでは具体的に個々の GC ポリシーについて見ていくことにします。 3-3-4-3 Optimize for Throughput (-Xgcpolicy:optthruput) まずはデフォルトの GC ポリシーである Optimize for Throughput について解説します。以降表題ととも に GC ポリシーを説明する際に JVM に渡す引数を併せて記載します。この GC ポリシーはデフォルトの ポリシーであるため、この GC ポリシーで JVM を稼動するときには特に明示的に指定しなくても構いませ ん。 この GC ポリシーはガーベッジ･コレクションを Mark-Sweep-Compaction の三つのフェーズに分けて実 施します。Mark フェーズではヒープ内のすべての「生きている」オブジェクトにしるし(Mark)をつけます。 Sweep フ ェ ー ズ は 、 し る し の つ い て い な い オ ブ ジ ェ ク ト を 、 ヒ ー プ 内 か ら 掃 き と り (Sweep) ま す 。 Compaction フェーズはヒープ上に存在しているすべてのオブジェクトをヒープのアドレス領域の一端に まとめる作業が行われます。Mark フェーズと Sweep フェーズはそれぞれそれほど大きな負荷とならない ため毎回の GC で実施されます。それに対して Compaction フェーズはオブジェクトの移動が伴うため 個々のオブジェクトのコピーとメモリアドレス情報の再構成が行われます。そのため先の二つのフェーズ と比べると負荷の大きな作業になるため、Compaction フェーズは発生条件が整ったときにのみ実施され ます。例えば Mark&Sweep が行われた後にヒープ･アロケーションを行えるだけの十分な空き領域が Free list にできなかった場合や、開放できた領域が少なくて全体の空き領域が一定以下だった場合で す Systemgc()コールの場合を除いて、Compaction は必ず一度ガーベッジ･コレクションが実施された後 に行われます。 以下に各フェーズにおけるヒープ状況のイメージを示します。 ガーベッジ・コレクション実施直前： Mark＆Sweepフェーズ実施後： Compactionフェーズが実行された場合： 空き領域 図 3-39 割り当て済みの領域 Optimize for ThroughputGC ポリシーのガーベッジ・コレクション 以下に挙げる図は JVM のアプリケーション･スレッドの稼動状況を時間軸に沿って見てみた場合のイ メージです。ガーベッジ･コレクション実行中はヒープへのアクセスを行っているすべてのスレッドが停止 するため、アプリケーションによるクライアントへのサービスもガーベッジ･コレクションが終了するまで停 止します。ちなみに、ヒープへのアクセスを行っていないスレッドと GC を実施しているスレッド(Allocation Failure となったアプリケーション･スレッドがそのまま GC を実施します)はガーベッジ･コレクション中も稼 動できるようになっています。 スレッド1 スレッド2 スレッド3 … スレッドn 時間 アプリケーション処理 ガーベッジ・コレクション(アプリケーション処理停止) 図 3-40 アプリケーション・スレッドとガーベッジ・コレクションの関係(Optimize for Throughput) (参考)ヒープ･ロックとスレッド･アロケーション･キャッシュ Optimize for Throughput ではひとつのヒープをすべてのスレッドが共有しています。あるスレッドがヒー プ･アロケーションを行っているとき、そのスレッドはヒープ内の整合性を保つためにヒープに対するロッ クを JVM から取得します。その間は他のスレッドはヒープ･アロケーションを行うことができないため、複 数 CPU によって JVM を稼動している場合はあまり効率がよくありません。そのためなるべくロック待ちの 時間を少なくする目的で、個々のスレッドは独占的に使用できる空き領域を Free list から常にひとつず つ確保して使用しています。これをスレッド･アロケーション･キャッシュ(Thread Allocation Cache)、または スレッド･ローカル･ヒープ(Thread Local Heap)と呼びます。この領域内ではロックを使用することなくヒー プ･アロケーションが可能になるため、その分ロック待ちが無くなります。スレッド･ローカル･ヒープを使い 果たすと、スレッドは Free list からまた新たな空き領域をひとつ確保して、それをスレッド･ローカル･ヒー プ用の領域として使用します(スレッド･ローカル･ヒープの領域取得はオブジェクトに対するヒープ･アロ ケーションと同じですので、取得時にはヒープ・ロックがかかります)。メモリー分断化(フラグメンテーショ ン：Fragmentation)が発生しているときは Free list 内の個々の空き領域の大きさが小さくなっています。そ のためスレッド･ローカル･ヒープとして割り当てることのできる領域も小さいので頻繁に新しい領域の取 得が行われます。つまりフラグメンテーション発生時には Compaction の多発に加えてヒープ・ロックも多 発するという副次効果が発生することで、さらにパフォーマンスの低下に追い討ちをかける状況が生ま れます。 (参考)ラージ･オブジェクト･エリア JVM にはオブジェクトのサイズとして大きな部類と見なされる（64K バイトを超える）ようなものを格納する 領域が用意されています。これがラージ･オブジェクト･エリアと呼ばれている領域です。デフォルトではヒ ープサイズの 5%がラージ・オブジェクト・エリアとして確保されており、その後ヒープ内に割り当てられる アプリケーションのオブジェクトサイズに応じて最大 50%、最小 0%の間で領域の大きさが変動します。度 重なるガーベッジ・コレクションによって Free list 内の個々の空き領域が小さくなっていったような時に比 較的大きなサイズのオブジェクトの割り当てにラージ・オブジェクト・エリアが使用されることで Compaction フェーズを回避することができ、結果としてパフォーマンスの低下を防ぎます。負荷の高い Compaction フェーズをなるべく回避するための一方策としてラージ・オブジェクト・エリアが提供されてい ますが、なるべく大きなオブジェクトをアプリケーションで生成しないでこの領域を使用しないように心が けること大切です。なお IBM JDK 1.4.1 以前ではラージ・オブジェクト・エリアは Wilderness 領域と呼ばれ ていました。 3-3-4-4 Optimize for Pause Time (-Xgcpolicy:optavgpause) Optimize for Throughput では、JVM がガーベッジ・コレクションを実施している最中は、アプリケーショ ン・スレッドの活動が止まっています。つまり、運悪くリクエストの到着がガーベッジ・コレクションの時間帯 にかぶってしまうと、ガーベッジ・コレクションによるリクエスト処理の停止の影響を受けるので、その分レ スポンスが遅れます。ガーベッジ・コレクションが長くなるとその分最大レスポンス・タイムも大きくなる可 能性が出てくるわけです。アプリケーションやシステムのパフォーマンス要件によってはスループットより もレスポンス・タイムのばらつきが小さいことがより優先されるケースもあります。そのような場合に検討対 象になる GC ポリシーがこの Optimize for Pause Time です。ヒープ管理のアルゴリズムはデフォルトと同 じ Mark-Sweep-Compaction 型を採用しつつ、文字通りガーベッジ・コレクションによる JVM の停止時間 を最小化するために最適化されたポリシーとなっています。簡単に説明するとリクエスト処理している時 間帯に Mark 処理もこまめにやってしまうことで停止時間を短縮しようというのがこのポリシーで採用され ている方法です。各アプリケーション・スレッドはあるタイミングからヒープ・アロケーションを実施する度 に、自身の所有するスタックから到達可能なオブジェクトを追跡し Mark していく作業を行います(この段 階を Concurrent フェーズとも呼ぶことから、この GC ポリシーのは Concurrent Mark とか Concurrent GC とも呼ばれます)。また、優先度の低いスレッドをバックグラウンドで起動して、CPU のアイドル時間を利用 して Mark 処理を並行して実施します。これらの事前作業を行うことで、ガーベッジ・コレクション時のアプ リケーション・スレッドの停止時間を短縮します。ただし、ガーベッジ・コレクションの前に処理を行うため に、スレッドによって事前にスキャンされたヒープ領域の状態がガーベッジ・コレクション実施時には変わ っている場合もあります。例えば、スキャン後に新たにオブジェクトがその領域に生成されたような場合 です。そのため、ガーベッジ・コレクションの実施時にはヒープを複数の領域に分け、それぞれの領域で スキャン後に変更された形跡があるかどうかをチェックして、変更されている領域は再スキャンが行われ ます。 この GC ポリシーはデフォルトの Optimize for Throughput と比べるとスループットの面で不利になりま す。特に Concurrent フェーズにおいて個々のアプリケーション・スレッドがリクエスト処理を行いながら Mark 作業を行うので、このフェーズが長くなればなるほどスループットは低下します。スループット低下 の度合いが高くなるか低くなるかは、並行して実施されている Mark 処理をバックエンドで行っているスレ ッドの処理がどれだけ多く実施できるかによります(つまり CPU のアイドル時間を獲得できる見込みのあ るシステムでは有利となります)。また、アプリケーションやシステムの特性によっては再スキャンの割合が 多くなって GC 時間の短縮が実現されない可能性も考えられます。 Optimize for Throughput の時と同様に Optimize for Pause Time 適用時の時間軸に対するスレッドの 稼動状況のイメージを以下に示します。GC の前に Concurrent フェーズによるリクエスト処理と Mark 処 理の併走時間が発生し、その間はアプリケーション処理だけでなく Concurrent トレース(Mark 処理)にも CPU 時間が配分されます。Optimize for Pause Time では Concurrent トレースによって Allocation Failure が発生する前に Mark 処理を事前に進めることで、実際にガーベッジ・コレクションが発生した時にアプリ ケーション・スレッドが停止する時間の短縮を実現します。 スレッド1 スレッド2 スレッド3 … スレッドn 時間 アプリケーション処理 ガーベッジコレクション Concurrentトレース 実施中は アプリケーション処理停止 図 3-41 アプリケーション・スレッドとガーベッジ・コレクションの関係(Optimize for Pause Time) 3-3-4-5 Generational Concurrent (-Xgcpolicy:gencon) IBM Developer Kit For Java 5.0、つまり WAS V6.1 から新たに加わった GC ポリシーがこの Generational Concurrent です。他の例と同様、名称がこの GC ポリシーの性質をよく表しており、一般に 「世代別 GC」と呼ばれる方法を採用しています。一言で Generational Concurrent の採用しているアルゴ リズムの特徴を述べると、個々のオブジェクトの想定される生存期間に応じて、ヒープ・アロケーションを 行う場所を変えながらヒープ全体を管理するというものです。具体的なヒープ管理方法を説明していきま す。ヒープを Nursery 領域と Tenured 領域と呼ばれる二つの異なる領域に分割します。新規に生成され るオブジェクトはまず Nursery 領域に割り当てられます。オブジェクトがある回数のガーベッジ・コレクショ ンをくぐり抜けて「生存」し続けることができると、オブジェクトは Nursery 領域から Tenured 領域に移され ます。生成されるほとんどのオブジェクトは数回のオーダーの回数のガーベッジ・コレクションのうちに消 滅する一方で、その期間中に生き残ったオブジェクトは比較的寿命が長いという一般則があります。そこ で、「短命」のオブジェクトに対して集中してガーベッジ・コレクションを行い、「長命」のオブジェクトはあ るタイミングで別の領域に待避させる手法をとることでガーベッジ・コレクションの効率を上げるというのが この GC ポリシーのアルゴリズムです。 Nursery 領域はさらに二つの領域に分かれ、一方を Allocate 領域、もう一方を Survivor 領域と呼びま す。ここで Generational Concurrent でのヒープモデルのイメージ図を以下に示します。 Nursery(New)領域 (Allocate領域) Tenured(Old)領域 (Survivor領域) 図 3-42 Generational Concurrent GC ポリシーにおけるヒープモデル 生成されるオブジェクトはまず Allocate 領域に格納されます。Allocate 領域がいっぱいになると、ヒー プ内の「生きた」オブジェクトのトレースが行われます。その際に、「生きた」オブジェクトがあるとそのオブ ジェクトを Survivor 領域にコピーをしていきます。これによって、Allocate 領域の全体のチェックが終わる と、「生きた」オブジェクトはすべて Survivor 領域にコピーされており、Survivor 領域を使ってこれ以降の リクエスト処理を行えるようになっています。そこで、Survivor 領域が新たに Allocate 領域として使用さ れ、元 Allocate 領域だったものは Survivor 領域となって次のガーベッジ・コレクションで再び役割が交代 するまで放置されます。この Nursery 領域を使用したガーベッジ・コレクションを Scavenger コレクションと 呼んでいます。Scavenger コレクションが行われている間は、デフォルトの Optimize for Throughput の時 と同じようにすべてのアプリケーション･スレッドは停止します。 以下に Scavenge コレクションの間に発生する Tenured も含めたヒープ全体の状態変化のイメージを示 します。Allocate 領域がいっぱいになると Nursery 領域でガーベッジ・コレクションが実施されます。原則 的に「生きた」オブジェクトは Survivor 領域にコピーをされますが、ある設定された閾値を超えるガーベッ ジ・コレクションを生き延びたオブジェクトは Survivor 領域ではなく Tenured 領域にコピーされます。 Nursery領域 Tenured領域 Scavenger コレクション 実施前： Scavenger コレクション 実施後： 空き領域 割り当て済みの領域 図 3-43 Scavengeｒコレクションの実行イメージ ある程度 JVM が稼動し続けていると大抵は Tenured 領域もオブジェクトでいっぱいになります。その中 には閾値を超えたガーベッジ･コレクションを生き延びたものの、すでにガーベッジとなってしまっている オブジェクトも存在します。そこで Tenured 領域に対してもガーベッジ・コレクションが実施されます。 Tenured 領域のガーベッジ・コレクションは Optimize for Pause Time と同じ方式がとられています。これに より Tenured 領域のガーベッジ・コレクションにかかる時間を短縮します。GC ポリシー名に「Concurrent」 とついているのはこの Tenured 領域に採用されたガーベッジ・コレクションの性質を表しているためで す。 なお、Scavenger 以外のコレクション、すなわち Mark-Sweep タイプのコレクションは Global コレクション という名称がつけられており、Scavenge および Glabal の名称は verbosegc ログの出力にも使用されてい ます。 以下に Generational Concurrent 適用時のスレッドの稼動イメージを示します。Nursery 領域を対象とし た Scavenger コレクションと、Tenured 領域を対象とした Concurrent トレースと Glocal コレクションが混在し ます。 スレッド1 スレッド2 スレッド3 … スレッドn 時間 アプリケーション処理 Scavengeコレクション Globalコレクション 実施中は アプリケーション処理停止 Concurrentトレース 図 3-44 アプリケーション・スレッドとガーベッジ・コレクションの関係(Generational Concurrent) (参考)TenuredAge オブジェクトの「年齢」はどれだけの回数のガーベッジ・コレクションを生き延びたかで判断されます。 Scavenger コレクションが実施されるたびに、JVM は生き残ったオブジェクトにひとつずつ「年齢」を加算 して管理を継続していきます。Tenured 領域へは閾値の回数だけ生き延びたオブジェクトのみが移動す ることができますが、この閾値は最大でも 14 です(つまり、タイムアウトをある程度長く設定した HTTPSession オブジェクトやデータ・ソースの Connection オブジェクトなどは最終的に Tenured 領域に格 納される可能性が高くなります)。この閾値は Nursery 領域内にとどまっているオブジェクトの割合によっ て JVM が調整を行っていて、生き延びているオブジェクトの占有率が 10%以下の場合閾値は 10 に、そ の後占有率の上昇とともに閾値も上がっていき、占有率が 30%を超えると最大値に到達します。 (参考)Nursery 領域の動的拡張 Generational Concurrent では Nursery 領域と Tenured 領域の両方のサイズを動的に変更することができ ます。最高のパフォーマンスを発揮させるための最適な Nursery 領域のサイズはその時々によって変わ ってくるため、JVM 汎用引数で明示的に固定する設定を取っていない限り、JVM はその時々に応じて ある期間の GC 総時間と GC の頻度からサイズ拡張または収縮を行います。 (参考)Tiltratio Nursery コレクションの実施間隔は tilting と呼ばれる技術によって最適化されています。これは生き残っ ているオブジェクトの総量に応じて Allocate 領域と Survivor 領域の割合を変更していきます。最初は 50%ずつから始まりますが、オブジェクトが蓄積されていくにつれて JVM は Survivor 領域が小さくなるよ うに割合を変更していきます。これによって無駄なヒープ領域をなるべく減らし、結果として Nursery コレ クションの実施間隔が長くなります。 (参考)Remembered Set と Write Barriers 一般論として、Generational Concurrent を適用している場合、Write Barrier と呼ばれる作業がパフォーマ ンスを低下させる要素としてあります。Write Barrier とは、Tenured 領域上のオブジェクトに何らかの更新 作業が入ると、当該オブジェクトが Nursery 領域に存在するオブジェクトをポイントしていないことをチェッ クする作業のことを言います。もし Nursery 領域上のオブジェクトをポイントしている場合、Scavenger コレ クションが起こるたびにポイント先オブジェクトのアドレス情報が変わります。そのため、JVM は Remembered set と呼ばれるコンポーネントに当該オブジェクト情報を記憶しておき、ガーベッジ・コレクシ ョンが実施される度にステータス情報の更新が行われます。通常は Nursery 領域のオブジェクトをポイン トしている Tenured 領域内のオブジェクトはそれほど多くないことや、J9 VM では Write Barrier のロジック の最適化を行っているため、パフォーマンス低下があまり起こらないようになっています。 3-3-4-6 Subpooling (-Xgcpolicy:subpool) これまで挙げた三つの GC ポリシーを適用するケースでは、適切なガーベッジ・コレクションのアルゴリ ズムを採用することで最適なパフォーマンスを得ることを目的としています。それに対して、これから紹介 する Subpool ポリシーの適用ではオブジェクトのヒープへの割り当て、つまりヒープ･アロケーションのア ルゴリズムを変更することで適切なパフォーマンスを得ることを目的とします。この GC ポリシーを適用す るには POWER アーキテクチャーの CPU を利用したプラットフォームであることが必要条件です。また、 一般に 8way 以上のシステムでの並列稼動を実施する場合に当 GC ポリシーの効果が期待できると言わ れています。 ヒープのレイアウトやガーベッジ・コレクションの方式はデフォルトの Optimize for Throughput とまった く同じです。違いは、ヒープの空き領域を管理する Free list がデフォルトではヒープ全体でひとつであっ たのに対して、この GC ポリシーを適用すると(名前にもある)Subpool と呼ばれる複数の Free list で管理 を行うところにあります。それぞれ Subpool はある大きさを持った空き領域(チャンク)が紐付けられてい て、条件にあったサイズのオブジェクト割り当て要求がくると適当な Subpool から割り当てを行います。こ れによってデフォルトの Optimize for Throughput のように Free list 内のチャンクを最初から検索する必要 がなく、複数の Free list が利用できるのでヒープ・アロケーションによって発生するロックの頻度を下げる こともできるため、パフォーマンス効率の高いアロケーションが実施できます。今説明したように、このポリ シーは沢山の CPU で稼動している JVM のヒープ･アロケーションによるロック待ちなどによるパフォーマ ンス低下を回避するためのものであるため、沢山の CPU を搭載していないシステムでは実施しても意味 がありません。多くの CPU で稼動している場合は逆にこのポリシーを適用しないと沢山 CPU を積んでい るにも関わらず期待したパフォーマンスが出ないという状況も発生する可能性がでてきます。 なお、この GC ポリシーが適用できないプラットフォームでヒープ・アロケーションの最適化を検討した い 場 合 は 、Generational Concurrent を利 用 す るこ とが 代替 策 とし て 利用 で き る場 合が あ りま す 。 Generational Concurrent では、Nursery 領域のヒープの利用方法を見ればわかるように、Free list で管理 する必要がそもそもなく、アドレスの端から順々にオブジェクトを配置していく仕組みになっているためで す。 3-3-4-7 Java ヒープサイズのチューニング ヒープサイズを適切に設定しておくことは JVM が適切なパフォーマンスを発揮する上で非常に重要 です。設定したヒープサイズが実際の必要量よりも少ないと Allocation Failure が相対的に多く発生しま すのでガーベッジ・コレクションの実施頻度が上がりますし、最悪の場合メモリー不足エラー (OutOfMemory)が発生してプロセスの稼動そのものができなくなる可能性も出てきます。また逆に大き すぎるヒープサイズを設定すると、ガーベッジ･コレクションの実施時間が長くなります。OS から割り当て 可能なサイズを超えて設定をしてしまうと、ページングが発生する恐れが出てきます。 ヒープサイズを調整する際は一般に二通りの考え方があります。 1. ヒープサイズを JVM に動的に変更できるように設定する： Generational Concurrent 以外の GC ポリシーを適用している場合、最大ヒープサイズを最小ヒープサイズよりも大きくすることで、差 分の範囲で JVM がヒープサイズ調整のアルゴリズムの則って動的にヒープを変更できるようにな ります。また、Generational Concurrent GC ポリシーを適用している場合は全体の最大サイズを決 めておけば、JVM が両方の領域のサイズをヒープサイズ調整のアルゴリズムの則って動的に変 更できるようになります 2. ヒープサイズを固定する(JVM に調整を任せない)： Generational Concurrent 以外の GC ポリ シーを適用している場合、最小ヒープサイズと最大ヒープサイズを同じ値にすることでサイズが固 定されます。また、Generational Concurrent GC ポリシーを適用している場合は Nursery 領域また は Tenured 領域のサイズを指定することで両方の領域のサイズが固定されます。 ヒープサイズの一般的な設定指針 ヒープサイズの決定においては、必要とするタイミングで必要な量だけのヒープを WAS（JVM）が確保 できるように必要十分なサイズを確保することが重要です。逆にこれができていないとガーベッジ・コレク ションが必要以上に発生し、メモリー不足エラーが発生するなどしてパフォーマンスや稼動そのものに 影響が出てきます。 WAS が Java ヒープを使用して保管するオブジェクトを、オブジェクト割り当ての発生タイミングという観 点でグループ化すると以下の図のようになります（なお、図中のグループ名称は便宜的につけたもの で、実際にこのような名称で呼ばれているわけではありません）。 この図の中で WAS の初期時に必ず必要になるコア部分にあたる Application Footprint 1 と WAS Footprint 1 の和を最小ヒープサイズに設定すると、初期化時に不要なヒープ拡張が発生することを回避 でき、起動パフォーマンスを向上させることができます。初期（最小）ヒープサイズ設定値を決定する際 は、verbosegc ログ（後述）を有効にしたうえで WAS の起動直後にどのくらいヒープが必要になっている のかを確認することでおおよその値を決定することができます。 Application Footprint 2 • 稼動環境(アクセス数など)に依存（変動） • オブジェクト(ex. 結果セットなどの一時利用変数) • アプリのコア部分(固定) • アプリケーションクラス • 前提リソース (ex. フレームワーク) など Application Footprint 1 • WASのコア部分(固定) • WASランタイム 図 3-45 • ユーザー設定に依存（変動） • 各種スレッドプール WAS Footprint 2 • XMLパーサー • ORB • JMX • セキュリティAPI • クラスローダー など • HTTPセッション • dynacache • 各種リソース • 接続プール • 各種キャッシュ • Prepared statement • EJBのキャッシュ など • 各種ログ など WAS Footprint 1 WAS のメモリ・フットプリント概略 WAS が起動した後、実際にリクエスト処理を行なっていくと、処理に必要なオブジェクトが適宜ロード されていきます。図の WAS Footprint 2 や Application Footprint 2 の中に分類しているものが該当しま す。スレッド・プールや接続プールなど、WAS の設定パラメーターに多く依存する WAS Foortprint 2 の 部分はテストフェーズにて実際に負荷をかけ、実際に最大数をロードしたタイミングでの verbosegc ログ から必要なサイズの見積もりを行ないます。 Application Footprint 2 に分類されるオブジェクトの総サイズは稼動中のタイミングと条件によって大き く変わってきます。HTTP セッション・オブジェクトを例にとると、セッションを有効にしている状況では WAS に入ってくるリクエストの数に比例してオブジェクトが生成されますし、各オブジェクトのサイズもユ ーザーの画面遷移やアクションによって変わってきます。そのためこの部分の見積もりについては、事 前にアプリケーション・サーバーの 1 プロセスあたりどのくらいのリクエスト受付を受容するかなどを決定し た上で負荷テストを行ない、適切なサイズを決定するのが望ましいと言えます。 Generational Concurrent 以外の GC ポリシー適用時のチューニング Generational Concurrent を GC ポリシーとして設定してない場合、ヒープは Mark&Sweep 方式による Global コレクションが実施される領域と言い換えることができ、ヒープは JVM 内にひとつの領域として存 在ます。設定できる箇所は初期ヒープサイズ(これが最小値となります)と最大ヒープサイズとなり、それぞ れ-Xms,-Xmx の引数を JVM 初期化時に渡すことで設定できます。 設定例 システムの稼動状態にあわせて、ヒープサイズを JVM に動的に変更させることを許可する場合、最大 ヒープサイズを初期ヒープサイズよりも大きく設定します。また、ヒープサイズを固定する場合は初期ヒー プサイズと最大ヒープサイズの大きさを同じにします。 ヒープサイズ可変 -XmsAm –XmxBm 0 A B ヒープサイズ固定 -XmsBm –XmxBm 0 B 図 3-46 デフォルト型のヒープサイズ設定 以下にいくつか具体例を示します。なお、WAS におけるヒープサイズの設定は例のように汎用 JVM 引数に設定を記述してもよいですし、管理コンソールの該当するサイズ入力欄に記入してもどちらでも かまいません。 -Xgcpolicy:optthruput –Xmx768m このケースではデフォルトの GC ポリシーである Optimize for Throughput を採用し、最大ヒープサイズを 768MB に指定しています。初期ヒープサイズは明示的な指定が行われていませんので、JVM 初期化 時には、デフォルトの初期ヒープサイズが確保されます。デフォルトの初期ヒープサイズは稼動プラットフ ォームによって異なり、例えば分散系の 32bit 環境では 50MB となります。初期化プロセスやリクエスト処 理等によって初期ヒープサイズでは足りなくなると、JVM は 768MB を上限として適宜ヒープの拡張を行 います。大抵の場合、WAS を起動するのに初期ヒープサイズでは足りませんので、ヒープ拡張が入るこ とでサーバー起動時間が長くなる可能性がありますので、WAS の起動時に必要とするヒープサイズを初 期ヒープサイズとして設定しておくとよいでしょう。なお、Optimize for Throughput はデフォルトの GC ポリ シーですので-Xgcpolicy: optthruput の記述は行わなくても構いませんが、この例のようにどの GC ポリシ ーを使用しているかを明示的に指定しても問題ありません。 -Xgcpolicy:subpool –Xms768m –Xmx1024m このケースでは Subpooling ポリシーを適用して、WAS 初期化時にヒープサイズを 768MB に指定してい ます。JVM は必要に応じて 1024MB までヒープサイズを拡張することが可能です。WAS 上の業務アプリ ケーションが時間帯によって利用状況に変化がある場合は、このケースのように最小値と最大値に差を つけておくとあまり使用されていない時にはマシンメモリの節約を行って、他のワークにメモリリソースを 渡すことができます。 -Xgcpolicy:optavgpause –Xms1024m –Xmx1024m このケースでは Optimize for Pause Time ポリシーを使用し、ヒープサイズを常に 1024MB 確保するように 設定しています。初期ヒープサイズと最大ヒープサイズを同じ大きさにしているため、WAS の利用率が高 くても低くても、JVM によるヒープの拡張や収縮は行われません。 Generational Concurrent GC ポリシー適用時のチューニング Global コレクションが行われるヒープの設定は、ヒープが複数に分かれていないため、先に挙げたと おり初期化時のサイズと最大サイズを決めるだけで、あとは JVM に運用を任せることができました。これ に対して、J9 VM から新たに採用された Generational Concurrent ではヒープを複数の領域に分けて管 理しているため、設定がこれまでよりも複雑になっています。こちらでも、主にガーベッジ・コレクションが 行われる Nursery 領域の使い方によって、設定に二つの方針があります。 1. Nursery 領域を小さく設定する： 主にガーベッジ・コレクションが行われる領域を小さくするこ とでガーベッジ・コレクションの頻度が上がりますが、Scavenger コレクション一回あたりの実施時間 を短くすることができます。そのため Nursery 領域を大きく設定したときと比べるとレスポンス・タイ ムが向上します。この設定方針は Tenured 領域へのオブジェクトのコピーが頻繁に起こるようなア プリケーションを稼動する場合にはお勧めしません。 2. Nursery 領域を大きく設定する： ガーベッジ・コレクションの頻度が上記方針に比べると低くな るため、スループットが相対的に向上しますただし、Scavenger コレクション一回あたりの実施時間 は長くなります。 設定例 Generational Concurrent を採用した場合のヒープは、Nursery、Tenured の各領域、および二つを合わせ た全体のヒープ領域の三つの設定ポイントがあります。このうち Nursery+Tenured 領域からなる全体のヒー プ領域の設定には Global コレクションの領域を定めたときと同じ-Xms、-Xmx を使用します。Nursery 領域 の設定は別名である new 領域のアルファベットの最初の n をとって、サイズを固定とする場合は-Xmn、動 的に変更を許可する場合の初期値は-Xmns、最大値は-Xmnx で指定します。Tenured 領域も同様に別名 の old 領域の頭文字をとって、固定とする場合は-Xmo を、動的に変更を許可する場合は-Xmos、-Xmox で指定します。 以下に設定例を出しますが、ポイントはそれぞれの領域で明示的に固定値、ないしは｛初期値、最大 値｝のペアを指定しないと、稼動中に JVM が動的にサイズを変更するということです。 Nursery領域 + Tenured領域 -XmsAm –XmxBm 0 B A 図 3-47 Generational Concurrent のヒープサイズ設定例： 全体の最小サイズ・最大サイズのみを指定するケース Nursery領域 Tenured領域 -XmnAm -XmoBm 0 図 3-48 A B 0 Generational Concurrent のヒープサイズ設定例： Nursery 領域と Tenured 領域のサイズを固定するケース Nursery領域 Tenured領域 -XmnsAm –XmnxBm 0 図 3-49 A -XmosCm –XmoxDm B 0 C Generational Concurrent のヒープサイズ設定例： Nursery 領域および Tenured 領域ともに動的な変更を許可するケース -Xgcpolicy:gencon –Xms768m –Xmx1024m このケースでは全体のヒープサイズの初期値、最大値のみを指定して、Nursery および Tenured 領域への 配分を JVM に動的に変更させる設定となります。ただし、ここで一点考慮点があります。Nursery 領域は 最大サイズを指定していない場合、64MB 以上には拡張されません。そのため、このケースでは Tenured 領域のみが 1024MB – (Nursery 領域のサイズ) を上限に拡張することができます。 -Xgcpolicy:gencon –Xmns64m -Xmnx256m -Xmx1024m D このケースでは Nursery 領域の初期サイズが 64MB で、最大 256MB まで拡張が可能です。また Tenured 領域は最大で 1024MB – (Nursery 領域のサイズ) まで拡張が可能になります。 -Xgcpolicy:gencon –Xmn128m -Xmx1024m このケースでは Nursery 領域を 128MB で固定しています。Nursery を固定しているので、Tenured 領域は 最大 1024 – 128 = 896MB まで拡張が可能になります。 -Xgcpolicy:gencon –Xmns128m –Xmnx512m –Xmo512m –Xmx1024m このケースでは Nursery 領域を初期値 128MB とし、最大 512MB までの拡張を許可しています。また tenured 領域は 512MB 固定しています。両方の領域の最大サイズがわかっているので、最後についてい る全体サイズの最大値を指定している-Xmx1024m の入力は必ずしも必要ではありません。ただし、最大 どれくらいの割り当てを行えるかをわかりやすくしておくためにこのように明示しておいても問題はありませ ん。 3-3-4-8 Java ヒープ・サイズの設定 WAS の Java ヒープ・サイズの設定は管理コンソールから可能です。[サーバー]→[サーバー・タイプ] →[WebSphere Application Server]→[ApplicationServer_name]→[サーバー・インフラストラクチャー] →[Java およびプロセス管理]→[プロセス定義]→[追加プロパティー]→[Java 仮想マシン] を選択し て、Java 仮想マシンの設定ページを表示します。 図 3-50 Java 仮想マシン設定 [初期ヒープ・サイズ]フィールドでは、JVM が起動時に確保するメモリー領域のサイズ（-Xms）を指定しま す。 [最大ヒープ・サイズ]フィールドでは JVM が確保できるメモリー領域の最大サイズ(-Xmx)を指定します。 [汎用 JVM 引数]フィールドでは JVM が起動時に読み込む引数を指定することができます。この欄に -Xms, -Xmx 引数でヒープサイズを指定することもできます。Generational Concurrent ポリシー適用時で、 Nursery/Tenured 領域の設定を行なう場合は他に設定欄がありませんので、汎用 JVM 引数に設定しま す。 3-3-4-9 V7.0 での JVM ランタイムの改良点 WAS V7.0 では一部のプラットフォームを除き、Java SE 6 の仕様に準拠した IBM SDK for Java Version 6 が採用されています。この JDK は前バージョンの 5.0 のテクノロジーをベースに開発されてお り、GC などの基本機能についての大きな変更点はありませんが、パフォーマンス面でいくつかの改良が 加えられています。ここではランタイム・プロビジョニング、共有クラスキャッシュ、参照の圧縮というパフォ ーマンス向上に有効な 3 つの機能について説明します。 3-3-4-10 ランタイム・プロビジョニング WAS ランタイムのパフォーマンスを向上させる機能として、V7.0 からランタイム・プロビジョニングという 機能が追加されました。V6.1 まではアプリケーション・サーバーが起動する際、Web コンテナーや EJB コ ンテナーなど全ての WAS 内部コンポーネントを起動していました。V7.0 ではランタイム・プロビジョニン グ機能を有効にすると、対象アプリケーション・サーバー上のアプリケーションや設定に応じて必要な WAS コンポーネントのみを起動します。例として、アプリケーション・サーバー上にデプロイしている全て のアプリケーションが Servlet、JSP のみで構成されている場合、EJB コンテナーや Web Service コンポー ネントなどは起動されません。これにより、平均して 10%程度アプリケーション・サーバーの起動時間が 短縮され、Heap 使用量も減少させることができます。このランタイム・プロビジョニングはデフォルト OFF で、デプロイメント・マネージャーやノード・エージェント、管理エージェント、ジョブ・マネージャーといっ た全ての JVM で設定できます。 図 3-51 ランタイム・プロビジョニング 3-3-4-11 ランタイム・プロビジョニングの有効化 ランタイム・プロビジョニングは管理コンソールから有効化することができます。[サーバー]→[サーバ ー・タイプ]→[WebSphere Application Server]→[ApplicationServer_name]画面にて [必要に応じてコ ンポーネントを開始]をチェックします。 図 3-52 ランタイム・プロビジョニング有効化設定 パラメーターの変更後は[適用]または[OK]ボタンを押下して、保管作業を行います。この設定は次回 のアプリケーション・サーバー起動時より有効になります。 3-3-4-12 共有クラスキャッシュ JVM のパフォーマンス向上の仕組みのひとつとして共有クラスキャッシュがあります。これは IBM JDK V5 で導入されたもので、複数の JVM 間で使用するクラスを共有する仕組みです。この機能を用いるこ とにより JVM の起動時間の短縮と使用メモリーのフットプリントを減少させることができます。共有クラス キャッシュは IBM JDK V5 で導入されましたが、V6 でいくつかの改良がされています。V5 では OS を再 起動させるとキャッシュ情報はクリアされてしまいましたが、V6 ではファイルに書き出すことによって OS 再起動をまたいでキャッシュ情報を保持させることが可能になっています。これにより OS 再起動後の最 初の JVM 起動時間の短縮を図ることができます。 図 3-53 共有クラスキャッシュ 3-3-4-13 共有クラスキャッシュの設定 共有クラスキャッシュの設定はデフォルトで有効になっていますが、無効化したいときは管理コンソー ルから設定することができます。[サーバー]→[サーバー・タイプ]→[WebSphere Application Server]→ [ApplicationServer_name]→[サーバー・インフラストラクチャー]→[Java およびプロセス管理]→[プロセ ス定義]→[追加プロパティー]→[Java 仮想マシン] を選択して、Java 仮想マシンの設定ページを表示 します。この画面の[汎用 JVM 引数]に“-Xshareclasses:none”を設定します。 図 3-54 共有クラスキャッシュの無効化 停止時にキャッシュ情報をファイルに書き出す機能もデフォルトで有効になっています。共有クラスキ ャッシュの機能を有効化したまま、この機能を無効化することも可能です。この場合は[汎用 JVM 引数] に“-Xshareclasses:nonpersistent”を設定します。また、ここに“-Xshareclasses:persistent”を設定するこ とにより、明示的に有効化することもできます。 詳細については以下の資料を参照下さい。 Java Diagnostics Guide 6 - Class data sharing command-line options http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.user.ai x32.60/user/sharedclassesxoptions.html 3-3-4-14 参照の圧縮 (Compressed references) V6.1 では 64bit 版は 32bit 版と比較してヒープ使用量が多く、比較すると 60％程度増加する傾向にあ りました。これはオブジェクト参照のポインターサイズは 32bit 版が 4 バイトであるのに対して 64bit 版では 8 バイトであるのが大きな原因でした。 V7 でも 64bit 版のヒープ使用量は 32bit 版と比較すると、V6.1 の場合と同程度大きくなりますが、ヒ ープ使用量を縮小する機能として参照の圧縮(Compressed references)が導入されています。これは文 字通り 64bit 版の 8 バイトの参照を 4 バイトに圧縮する機能でヒープ使用量の削減に効果があります。 ただし、ヒープサイズが 29GB 以下(サイズはプラットフォーム依存)の場合に限られ、Soraris 64bit JVM などサポートされないプラットフォームもあります。 3-3-4-15 参照の圧縮の有効化 参照の圧縮機能はデフォルトでは無効になっています。有効化するには管理コンソールからおこな い ま す 。 [ サ ー バ ー ] → [ サ ー バ ー ・ タ イ プ ] → [WebSphere Application Server] → [ApplicationServer_name]→[サーバー・インフラストラクチャー]→[Java およびプロセス管理]→[プロセ ス定義]→[追加プロパティ]→[Java 仮想マシン] を選択して、Java 仮想マシンの設定ページを表示し ます。この画面の[汎用 JVM 引数]に“-Xcompressedrefs”を設定します。 図 3-55 参照の圧縮の有効化設定 参照の圧縮の詳細については以下の資料を参照下さい。 Java Diagnostics Guide 6 - Compressed references http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.diagno stics.60/diag/understanding/mm_compressed_references.html 3-4 モニタリング・ツール パフォーマンス・チューニングを実施するにあたり、システムのどの部分がボトルネックとなっていて、 チューニングが必要なのかを見極めなければなりません。この節ではチューニングを実施する前段階と して行うモニタリングについて、主要なモニタリング・ポイントと使用するモニタリング・ツールの使用方法 を説明します。最後には、モニタリングの結果の解析について述べます。 3-4-1 Performance Monitoring Infrastructure WAS ではパフォーマンス・データを取得するために PMI というフレームワークを使用します。ここでは PMI とその設定方法について説明します。 3-4-1-1 概要 WAS ではアプリケーション・サーバーのパフォーマンス・データを取得するフレームワークとして PMI （Performance Monitoring Infrastracture）を提供しています。WAS では各リソースの様々なパフォーマン スデータを MBean(Managed Bean)という特別な JavaBean に格納しており、PMI はこの MBean と通信し て各コンポーネントの必要なパフォーマンスデータを取得します。パフォーマンス・データを格納してい る MBean は複数あり、それぞれ固有のデータを持っています。MBean には J2EE の仕様に定義されて いる J2EE 管理対象オブジェクトの MBeans と WebSphere PMI Perf MBean があります。J2EE MBeans は特定のコンポーネントに関するパフォーマンス・データを提供し、Perf MBean は WebSphere PMI サー ビスへのゲートウェイとして機能し、すべてのコンポーネントに対するパフォーマンス・データにアクセス します。 PMI ノード JVMヒープ使用率、JDBC接続プール数 Webコンテナースレッド使用率、セッショ ン作成数、GC発生率・・・・・ プラグイン Web サーバー MBean MBean MBean MBean MBean MBean MBean MBean DB MBean アプリケーション・サーバー PMI を使用してパフォ-マンス・データを取得するモニターツールとして、Tivoli Performance Viewer （以下、TPV）、パフォーマンス・サーブレット、JMX インターフェースがあります（PMI クライアント API は 非推奨となっています）。これらを使用して、PMI が取得したパフォーマンスの統計データを取得するこ とができます。 Tivoli Performance Viewer は WAS の管理コンソールに組み込まれているパフォーマンス・モニター・ツ ールです。パフォーマンス・サーブレットは、パフォーマンス・データを XML 形式で出力するサーブレッ トでこちらも WAS で提供されています。また、JMX インターフェースはユーザー独自のモニター・アプリ ケーションを開発する場合に使用します。 3-4-1-2 モニターできるデータ パフォーマンス・データは、それぞれのコンポーネントに対応したモジュールというカテゴリーでグルー プ化されています。モジュールには以下のものがあります。 －エンタープライズ Bean －JDBC 接続プール －J2C 接続プール －Java 仮想マシン（JVM） －オブジェクト・リクエスト・ブローカー（ORB） －サーブレット・セッション －トランザクション －スレッド・プール －Web アプリケーション －ワークロード管理（WLM） －システム －動的キャッシュ －Web サービス・ゲートウェイ（WSGW） －Web サービス －Alarm Manager －オブジェクト・プール －スケジューラー －高可用性マネージャー（HA マネージャー） －DCS スタック －システム統合バス（SIB) －ポートレット・アプリケーション －SipContainerModule 3-4-1-3 PMI 設定 PMI を使用してパフォーマンス・データを収集するためには、管理コンソールによって PMI を使用可 能にする必要があります。（ただし、WAS V7.0 では PMI はデフォルトで使用可能になっています。）管 理コンソールより[モニターおよびチューニング]→[Performance Monitoring Infrastructure (PMI)]→ [AppServer_name]を選択して、構成タブの[Performance Monitoring Infrastructure (PMI)を使用可 能にする]にチェックを付けると PMI は使用可能になります。設定変更後はアプリケーション・サーバーを 再始動する必要があります。 モニターできるパフォーマンス・データは統計のセットとして、表 3-6 に示す４つの定義済みの統計セ ットが提供されています。定義済みの統計セットの他に[カスタム]のリンクをクリックして、モニターするパ フォーマンス・データを選択することが可能です。デフォルトで[基本]となっているため、より多くのパフォ ーマンス・データをモニターするためには、[現在モニターされている統計セット]で[なし]、[基本]、[拡 張]、[すべて]、[カスタム]のいずれかにチェックを付けて、適切な統計セットを設定します。統計セットの 変更後はアプリケーション・サーバーを再始動する必要があります。 図 3-56 PMI 設定 統計セット なし 基本 拡張 すべて カスタム 説明 すべての統計を使用不可にします。 ランタイムおよびアプリケーション・コンポーネントに関する基本的なパフォーマンス・デー タを提供します。J2EE1.4 で指定された統計および CPU や HTTP セッションなどの基本的 な統計が使用可能になります。デフォルトの統計セットに設定されています。 ランタイムおよびアプリケーション・コンポーネントに関する詳細なパフォーマンス・データ を提供します。WAS コンポーネントの基本セットおよびキー統計が使用可能になります。 すべての統計が使用可能になります。 統計を選択して、モジュールごとに使用可能または使用不可に設定します。 表 3-6 統計セット 3-4-2 Tivoli Performance Viewer Tivoli Performance Viewer（以下、TPV）は管理コンソールに組み込まれた WAS のパフォーマンス・モ ニタリング・ツールです。TPV を使用することによって、管理コンソールから WAS の各リソースの状況を モニターすることができます。 3-4-2-1 モニターの開始 WAS の現在のリソース状況のモニター方法を説明します。TPV ではノード上のすべてのアプリケーシ ョン・サーバーとノード・エージェントがモニター対象となります。 ① 管理コンソールより[モニターおよびチューニング]→[Performance Viewer]→[現行アクティビティ] を選択するとアプリケーション・サーバーとノード・エージェントの一覧が表示されるので、モニター の対象のアプリケーション・サーバー、またはノード・エージェントにチェックボックスにチェックを付 けて、[モニターの開始]ボタンを押します。[コレクション状況]が[使用可能]から[モニター対象]に 変更することで、モニター開始が確認できます。この時点からパフォーマンス・データの収集が開 始します。 図 3-57 モニターの開始 ② モニター対象のアプリケーション・サーバー、またはノード・エージェントのリンクをクリックすると TPV コンソール・パネルが表示され、左側にナビゲーション・ツリー、右側に現行のパフォーマン ス・アクティビティのリアルタイムのデータが表示されます。 3-4-2-2 ユーザー設定およびロギング設定 TPV のモニターでは以下のユーザー設定およびロギング設定が可能です。 ユーザー設定 ユーザー設定では収集するパフォーマンス・データに関する以下の値の設定を必要に応じて行いま す。TPV コンソール・パネルのナビゲーション・ツリーより[設定]→[ユーザー]を選択し[ユーザー設定]ペ ージを表示します。 リフレッシュ速度 パフォーマンス・データを収集する間隔を秒単位で指定します。デフォルトでは３０秒です。指定可能な 数値は５秒から５００秒です。 バッファーサイズ 収集したデータを一時的に保管する際のデータ量を指定します。TPV で表示されるデータは、ノード・ エージェントのヒープ内のバッファーに保管されるため、バッファーがフルになった後は、古いデータか ら破棄されていきます。デフォルトのバッファーサイズは４０です。指定可能な値は１０から１００です。バ ッファー・サイズが大きいとそれだけ、ヒープを消費するので適切な設定をする必要があります。 データ表示 収集したデータの表示方法を設定します。以下の選択が可能です。 − 生データ：収集したデータの絶対値を表示します。 − 値の変化：直前の値と現行までの値の変化を表示します。 − 変化率：値の変化を時間で割った値を表示します。 図 3-58 ユーザー設定 ロギング設定 ロギング設定ではロギングに関する以下の設定を行います。 期間 [ロギング開始]をしてから[ロギング停止]を行わない限り、ロギングを継続する時間を設定します。デフォ ルトでは２０分です。 最大ファイルサイズ ひとつのログ・ファイルのサイズを指定します。TPV ではログ・ファイルを自動で ZIP 形式に圧縮します が、このパラメーターは圧縮前のファイル・サイズの指定となります。 ヒストリー・ファイルの最大数 ログ・ファイルは循環ログとなっているため、TPV が書き込むファイルの最大数を指定します。 ファイル名 ログ・ファイルのプレフィックスを指定します。実際のファイル名は以下のようになります。 <prefix>_<process_name>_<timestamp>_<suffix_number>.zip ログ出力フォーマット ログ・ファイルのフォーマットを XML もしくはバイナリーに指定します。バイナリーの方がログ・ファイルの 解凍後のファイル・サイズは小さくなります。 図 3-59 ロギング設定 3-4-2-3 現行アクティビティの表示（パフォーマンス・モジュール） TPV コンソール・パネルのナビゲーション・ツリーの[パフォーマンス・モジュール]を展開すると、TPV で取得できる WAS のモニター項目が表示されます。チェック・ボックスにチェックを付けたモニター項目 についてビューアーに表示されます。[モジュールの表示]ボタンを押すことで、ビューアーにグラフ表示 されます。（PMI は指定したレベルの全データを取得していますが、ビューアーに表示されるのはチェッ クを付けたモニター項目のみです。） 図 3-60 現行アクティビティの表示 ビューアーにおけるデータ表示 • グラフの表示 取得データを 図 3-60 のようにグラフ表示 • 表の表示 取得データを表形式で表示 • バッファーのクリア 表、またはグラフ形式で現在ビューアーに表示されている値を削除します。データ取得の停止後 に実施すると、ビューアー上のデータが削除されます。 • ゼロにリセット 取得されるデータには、取得開始からの相対値を表すデータと、取得時のリアルタイムでの値を 表すデータがあります。データが相対値である場合、この操作によってデータはゼロにリセットさ れ操作時点を開始時刻としてデータの表示が再開されます。データがリアルタイムの状態を表す ロード・データである場合、リセットはできないので影響はありません。この操作を行うと、[バッファ ーのクリア]での操作も同時に行われます。 • 名前 グラフのマーカーに対応する値については、ビューアー下に表形式で表示されます。[名前]にカ ーソルを当てると値の説明を確認することができます。 • 尺度 グラフに表示する値の倍率を設定することができます。実際の値に[尺度]を乗じた値（「尺度の 値」）がグラフに表示されます。 3-4-2-4 モニタリング・ポイント Web システムにおいてパフォーマンスを考慮する場合の主要なモニタリング・ポイントとして以下の図 に示す 10 項目がありますが、ほとんどの項目については Tivoli Performance Viewer を使用してモニタ ーすることができます。これらの主要モニタリング・ポイントについて Tivoli Performance Viewer のどのパ フォーマンス・モジュールでモニターしていくのかについて説明します。 図 3-61 Web システムにおけるモニタリング・ポイント 1). 平均応答時間 サ ー ブ レ ッ ト の 平 均 応 答 時 間 は パ フ ォ ー マ ン ス ・ モ ジ ュ ー ル [Web ア プ リ ケ ー シ ョ ン ] の [ServiceTime]で Web コンテナー上のサーブレットの平均値をモニターすることができます。 2). スループット スループットはパフォーマンス・モジュール[Web アプリケーション]の[RequestCount]でモニター することができます。以下の表に、[Web アプリケーション]で取得できるデータを示します。 名前 統計セット 説明 Loaded Servlet Count すべて ロードされたサーブレットの数 Reload Count すべて 再ロードされたサーブレットの数 Request Count 基本 1 つのサーブレットが処理したリクエストの合計数 Concurrent Requests 拡張 同時に処理されるリクエスト数 Service Time 基本 サーブレットのリクエストが終了する平均応答時間（ミリ秒） Error Count 拡張 サーブレットと JSP ファイルにおけるエラーの総数 URIRequestCount 基本 サーブレットに関連付けられた URI に対して処理された要 求の総数 URIConcurrentRequests 拡張 サーブレットに関連付けられた URI に対して同時に処理され る要求の数 URIServiceTime 基本 サーブレットに関連付けられた URI に対する平均サービス 応答時間 (ミリ秒) 3). HTTP セッション数 ＨＴＴＰセッションオブジェクト数はパフォーマンス・モジュール[サーブレット・セッション・マネージャ ー]の[LiveCount]でモニターすることができます。HTTP セッションについてはその他にも、以下 の表に示すデータを[サーブレット・セッション・マネージャー]でモニターすることができます。 名前 統計セット 説明 CreateCount すべて 作成されたセッションの合計数 InvalidateCount すべて 無効になったセッションの合計数 LifeTime 拡張 セッションの平均存続時間（ミリ秒） ActiveCount すべて 同時にアクティブなセッション数。ＷＡＳがセッションを使用す るリクエストを処理している場合、セッションはアクティブとな る。 LiveCount 基本 メモリー内にあるセッション数 NoRoomForNewSessi 拡張 「オーバーフローの許可」がチェックされていない際に適用。新 規セッションの要求を処理できない合計回数。 onCount CacheDiscardCount すべて 分散セッションでキャッシュから破棄されたセッションの合計数 ExternalReadTime 拡張 分散セッションで、外部からセッション・オブジェクトを読み取る のにかかった時間（ミリ秒） ExternalReadSize 拡張 分散セッションで、外部から読み取ったセッション・オブジェクト のサイズ ExternalWriteTime 拡張 分散セッションで、外部にセッション・オブジェクトを書き込むの にかかった時間（ミリ秒） ExternalWriteSize 拡張 分散セッションで、外部に書き込んだセッション・オブジェクトの サイズ AffinityBreakCount すべて フェイル・オーバーなどで中断されたアフィニティの合計数 TimeSinceLastActivate すべて セッション・オブジェクトに対してのアクセス間隔の平均時間（ミ リ秒） d TimeoutInvalidationCo すべて タイムアウトにより無効になったセッションの数 すべて タイムアウトが原因で存在していないセッションに対するリクエ unt ActivateNonExistSessi ストの合計数 onCount SessionObjectSize すべて メモリー内のシリアライズ化されたセッション・オブジェクトのサ イズ 4). Web サーバー・スレッド Web サーバー・スレッドのモニタリングは、Tivoli Performance Viewer ではできません。「3-3-2-2 IBM HTTP Server のモニタリング」を参照して下さい。 5). スレッド・プール Web コンテナー・スレッド・プールの情報はパフォーマンス・モジュール[スレッド・プール]→ [WebContainer]でモニターすることができます。 ORB スレッド・プールの情報はパフォーマンス・モジュール[スレッド・プール]→[オブジェクト・リク エスト・ブローカー]でモニターすることができます。 各スレッド・プールについて取得可能なデータは同じになります。以下の表に、[スレッド・プール] でモニターできるスレッド・プールのデータを示します。 名前 統計セット 説明 CreateCount すべて 作成されたスレッドの合計数 DestroyCount すべて 破棄されたスレッドの合計数 ActiveCount 拡張 同時にアクティブなスレッドの数とその平均値 PoolSize 基本 プール内のスレッドの数とその平均値 PercentMaxed すべて プール内のすべてのスレッドが使用中である時間の平均比率 （％） DeclaredThreadHung すべて ハング宣言されたスレッドの総数 すべて クリアされたハングスレッド数 Count ClearedThreadHungC ount ConcurrentHungThrea すべて 同時に停止したスレッド数 すべて スレッドがアクティブな状態である平均時間（ミリ秒） dCount ActiveTime 6). データ・ソース接続プール アプリケーションでデータ・ソースを使用してデータベースへの JDBC 接続を行っている場合に、 データ・ソースごとに接続プールの情報をモニターすることができます。 パフォーマンス・モジュール[JDBC 接続プール]→[JDBCProvider_name]→[JNDI_name]でモ ニターするデータ・ソースの JNDI 名にチェックを付けます。 以下の表に、[JDBC 接続プール]でモニターできる接続プールのデータを示します。 名前 統計セット 説明 CreateCount 基本 getConnection()によってプールに作成された接続数の合計 CloseCount 基本 保守スレッドサービスによってプールから破棄された接続数の 合計 AllocateCount すべて getConnection()によって使用されたプール内の接続数の合 計 ReturnCount すべて close()によって未使用になったプール内の接続数の合計 PoolSize 基本 プールにある接続数 FreePoolSize 基本 プールにある空き接続数 WaitingThreadCount 基本 プール内に使用可能な接続がなく同時に接続待ちをするスレ ッド数 FaultCount 拡張 待機状態のスレッドが接続タイムアウトになる回数の合計 PercentUsed 基本 プール内の接続の使用率の平均パーセント PercentMaxed すべて すべての接続が使用中である時間の平均パーセント UseTime 基本 接続が使用される平均時間（接続が割り振られる時刻から戻 される時刻までの時間）（ミリ秒） WaitTime 基本 接続が割り振られるまでの平均待ち時間（ミリ秒） ManagedConnectionC すべて プール内の接続数（物理接続数） すべて getConnection()によって割り振られた接続ハンドルの数 拡張 廃棄された PreparedStatement の合計数 拡張 JDBC ドライバー内での実行にかかった時間（ミリ秒） ount ConnectionHandleCou nt PrepStmtCacheDiscar dCount JDBCTime 7). JVM メモリー アプリケーション・サーバーとノード・エージェントの JVM の情報をパフォーマンス・モジュール[JVM ラン タイム]でモニターすることができます。デフォルトでは以下の表に示すデータがモニターできますが、 JVMTI（JVM Tool Interface）を使用可能にすることで、ガーベッジ・コレクションなどの詳細データをモ ニターすることもできます。ただし、JVMTI を使用することによってパフォーマンスが低下するので注意 が必要です。 JVM ランタイム 名前 統計セット 説明 HeapSize 基本 JVM ヒープサイズ(KB) FreeMemory 拡張 ヒープの空きメモリー・サイズ(KB) UsedMemory 基本 ヒープの使用メモリー・サイズ(KB) UpTime 基本 JVM が起動してからの経過時間（ミリ秒） ProcessCpuUsage 基本 JVM の CPU 使用率（%） 以下は、アプリケーション・サーバーの JVM の設定で JVMTI（Java Virtual Machine Tool Interface） を使用可能にすることで、モニターすることができます。 ガーベッジ・コレクション 名前 統計セット 説明 GCCount カスタム ＧＣが発生した合計数 GCIntervalTime カスタム 2 回のＧＣ間の平均時間（ミリ秒） GCTime カスタム 1 回のＧＣが要する時間の平均（ミリ秒） 名前 統計セット 説明 WaitsForLockCount カスタム Java スレッドがロック待ちする合計回数 WaitForLockTime カスタム Java スレッドがロック待ちする平均時間 モニター オブジェクト（このカウンターは WAS V6.1 以降では非推奨となっています。） 名前 統計セット 説明 ObjectAllocateCount カスタム ヒープ領域に割り当てられたオブジェクト数の合計 ObjectFreedCount カスタム GC によってヒープ領域から開放されたオブジェクト数の合計 ObjectMovedCount カスタム GC の Compaction によって移動したオブジェクト数の合計 名前 統計セット 説明 ThreadStartedCount カスタム 開始した Java スレッド数の合計 ThreadEndedCount カスタム 終了した Java スレッド数の合計 スレッド JVMTI（Java Virtual Machine Tool Interface）の使用可能設定 JVMTI を使用可能にするためには、ＪＶＭに対しての設定が必要になります。管理コンソールから[サー バー]→[サーバー・タイプ]→[WebSphere Application Server]→[ApplicationServer_name]→[サーバ ー・インフラストラクチャー]→[Java およびプロセス管理]→[プロセス定義]→[追加プロパティ]→[Java 仮想 マシン]を選択して、JVM の設定画面を表示します。汎用 JVM 引数の設定フィールドに 「-agentlib:pmiJvmtiProfiler」を入力して保管処理を行います。プロセスを再起動することによって、 JVMTI は使用可能になります。 3-4-2-5 ロギング Tivoli Performance Viewer（以下、TPV）のロギング処理では、取得データをログ・ファイルに出力して 残し、一定期間のリソース状況を再生することが可能です。 ログの取得 ログの取得方法を説明します。左側ツリーの上部に[モジュールの表示]ボタンを押して、ビューアーを表 示します。ビューアー上部の[ロギング開始]ボタンを押すとログの出力が開始します。ロギングを停止し たいタイミングで[ロギング停止]ボタン押してログ出力を停止します。 図 3-62 ロギング設定 ログ・ファイルの設定については「3-4-2-2 ユーザー設定およびロギング設定」のロギング設定を参照して 下さい。 ログの再生 ロギング処理で取得したログ・ファイルをビューアーで再生する手順を説明します。 ④ 管理コンソールのナビゲーション・ツリーから[モニターおよびチューニング]→[Performance Viewer]→[ログの表示]を選択して、ログ・ファイルの選択画面を表示します。 ⑤ [ログ・ファイルの明示的パス]にチェックをいれて、参照ボタンでログ・ファイルを選択します。ロ グ・ファイルは記録中には.xml（XML フォーマット）もしくは.tpv（バイナリーフォーマット）を拡張 子に持つファイルに出力されますが、記録停止後に自動的にファイルサイズ縮小のために ZIP 形式のファイルに圧縮されます。 ⑥ [ログの表示]ボタンを押すと、ビューアーが表示され、ログの再生が開始します。 図 3-63 ログファイルの選択 ⑦ TPV のツリーのパフォーマンス・モジュールからモニターするモジュールにチェックを付けて、 [モジュールの表示]ボタンを押すと、ビューアーにデータが表示されます。 ⑧ ビューアー上部のボタンでログ・ビューの調整が可能です。ログの表示が終了するまで、ログの 再生が行われます。 巻き戻し：ログファイルの最初に戻ります。 停止：現在の場所でログを停止します。 再生：現在の場所からのログを再生します。 高速前進：次のデータ・ポイントを 3 秒ごとにロードします。 高速前進 2：10 のデータ・ポイントを 3 秒ごとにロードします。 図 3-64 ログの再生 3-4-3 パフォーマンス・アドバイザー パフォーマンス・アドバイザーは WAS でパフォーマンス・チューニングのアドバイスを通知するツール です。パフォーマンス・アドバイザーには、Runtime Performance Advisor と Tivoli Performance Viewer で 提供される Performance Advisor（TPV Advisor）があります。共に PMI で取得したデータを元に、スレッ ド・プール、接続プール、Prepared Statement Cache、セッション、ヒープ・サイズなどのチューニングを示 唆します。使用するには PMI を使用可能にする必要があります。PMI はデフォルトでは使用可能になっ ています。設定については 3-4-1-3PMI 設定(p.73)」を参照して下さい。 Runtime Performance Advisor Runtime Performance Advisor はアプリケーション・サーバー上で稼動し、パフォーマンスを定期的に チェックしてパフォーマンス・チューニングに関するアドバイスを管理コンソールの[WebSphere ランタイ ム・メッセージ]と標準出力である SystemOut.log ファイルに出力します。Runtime Performance Advisor を 使用することによるシステムへの負荷はほとんどありません。 Runtime Performance Advisor はデフォルトでは使用可能になっていません。管理コンソールから[サ ーバー]→[アプリケーション・サーバー]→[ApplicationServer_name]→[パフォーマンス]→[Runtime Performance Advisor 構成]を選択して Runtime Performance Advisor 構成ページを表示します。構成タ ブの一般プロパティで[Runtime Performance Advisor を使用可能にする]のチェックボックスにチェック を付け、[適用]または[OK]ボタンを押下し保管処理を行います。アプリケーション・サーバーを再始動す ることで Runtime Performance Advisor は使用可能になります。ランタイムタブで設定を行った場合は、ア プリケーション・サーバーの再始動は必要ありません。 図 3-65 Runtime Performance Advisor 以下のリソースに対してのアドバイスを通知します。 ORB サービス・スレッドプール Web コンテナー・スレッドプール 接続プールサイズ Persisted セッション・サイズおよび時間 Prepared Statement キャッシュ・サイズ セッション・キャッシュ・サイズ TPV Advisor TPV Advisor は TPV 上で使用されるもので、管理コンソールでリソースの状況やアドバイスを表示しま す。Runtime Performance Advisor によるアドバイスに加えて、動的キャッシュ、JVM ヒープ・サーズなど のアドバイスが通知されます。TPV コンソール・パネルのナビゲーション・ツリーの[アドバイザー]を選択 して TPV Advisor を表示します。更新間隔は TPV と同様に指定することが可能です。設定方法につい ては、3-4-2-2 ユーザー設定およびロギング設定(p. 75 )」を参照して下さい。 図 3-66 TPV アドバイザー パネル上部の表では Web コンテナーと EJB コンテナーにおける要求数/秒と応答時間(ミリ秒)を表示し ます。円グラフでは CPU の使用時間とアイドル時間のパーセンテージを表示しています。 パネル中部の表では、各スレッド・プール、接続プールの使用状況を表示します。 以下のリソースに対してのアドバイスを通知します。 ORB サービス・スレッドプール Web コンテナー・スレッドプール 接続プールサイズ Persisted セッションサイズおよび時間 Prepared Statement キャッシュ・サイズ セッション・キャッシュ・サイズ 動的キャッシュ・サイズ JVM ヒープ・サイズ DB2 Performance Configuration Wizard 3-4-4 要求メトリック Performance Monitoring Infrastructure(PMI)要求メトリックは、Web コンテナー、ＥＪＢコンテナー、デー タベースなどの主要コンポーネントにおいて経過した時間を計測し、ログに記録する機能です。リクエス トが WAS 内でコンポーネント間の移動にかかった時間を測定することができるので、実行環境とアプリケ ーションのパフォーマンス問題を識別するのに役立ちます。 実稼動環境での稼動を考慮し、IP アドレスまたは URI、EJB メソッド、JMS パラメーター、Web サービ ス・パラメーターによりフィルター操作することができます。フィルタリングすることでパフォーマンスの劣 化を防ぐことができます。 計測対象コンポーネント 以下の中から選択したコンポーネントを対象として、リクエストが入ってから出るまでの経過時間を計測 し、ログに出力します。 − Web サーバー・プラグイン − プロキシー・サーバー − Web コンテナー − ＥＪＢコンテナー − データベース − JCA（J2EE コネクター・アーキテクチャー） − Web サービス − JMS − サービス統合バス − ポートレット・コンテナー − 非同期 Bean 3-4-4-1 基本使用方法 要求メトリックの基本的な使用方法についての手順を説明します。 ① 管理コンソールのナビゲーション・ツリーから[モニターおよびチューニング]→[要求メトリック]を 選択して要求メトリックの設定画面を表示します。デフォルトでは要求メトリックは使用可能にな っています。要求メトリックを使用しない場合は、[要求メトリック・コレクション用のサーバーの準 備]のチェックを外します。 ② 計測対象とするコンポーネントを[計測対象コンポーネント]から選択します。[カスタム]を選択す ると複数の任意のコンポーネントを選択可能です。 ③ [要求メトリックの宛先]の[標準ログ]にチェックを付けて、要求メトリックで取得するデータのロ グ・ファイルへの出力をＯＮにします。この設定を行わないとログへ出力されませんので注意が 必要です。ログは SystemOut.log に出力されます。 ④ 設定を終えたら、[OK]ボタンを押して、構成の保管を行います。 ① 要求メトリックで Web サーバー・プラグインを計測対象とする際には、Web サーバー・プラグイ ンの構成ファイルに設定が反映されます。したがって、管理コンソールからプラグインの生成を 行う必要があります。 図 3-67 要求メトリック設定 3-4-4-2 トレース・レベルの設定 トレース・レベルの設定では、要求メトリックで取得するデータの詳細レベルを設定します。以下のレ ベルから選択します。（[なし]よりも高いレベルを設定します。） • なし：トレースを取得しません。 • ホップ：プロセス境界のみの計測情報を取得します。 • パフォーマンス・デバッグ：ひとつの追加レベルの計測データを取得します。 • デバッグ：すべてのプロセス内のサーブレットおよび EJB 呼び出しの応答時間を含む、詳細な計 測データを提供します。 3-4-4-3 フィルターの設定 要求メトリックのオプション機能としてフィルターを使用することによって、特定の箇所のみのトレースを 取得することが可能です。要求メトリックを使用すると、ログファイルに大量のデータを出力するためにパ フォーマンスの劣化を招きかねません。フィルターを使用して、取得するデータを限定することによっ て、パフォーマンスの劣化を防ぐことができます。 HTTP リクエストに対するフィルター WAS が受ける HTTP リクエストに対して、「送信元 IP アドレス・フィルター」と「URI フィルター」を使用し てフィルタリングが可能です。 • 送信元 IP アドレス・フィルター HTTP リクエストの送信元の IP アドレスに基づいてフィルターを掛けます。 • URI フィルター ＨＴＴＰリクエストのＵＲＩに基づいてフィルターを掛けます。 送信元 IP アドレス・フィルターと URI フィルターを両方とも設定した場合、要求メトリックでは、両方のフィ ルター・タイプに一致する必要があります。 EJB リクエストに対するフィルター EJB リクエストに対して、「EJB メソッド名フィルター」を使用して、フィルタリングが可能です。 • EJB メソッド名フィルター EJB メソッドの絶対パス名に基づいてフィルターを掛けます。 JMS フィルター JMS リクエストに対して、キュー宛先名およびトピック宛先名に基づいてフィルターを掛けます。 例：destination=aaa:topic=bbb Web サービス・フィルター Web サービスのリクエストに対して、WSDL のポート名、オペレーション名、トランスポート名の組み合 わせに基づいてフィルターを掛けます。 例：wsdlPort=aaa:op=bbb:namespace=ccc 3-4-4-4 ログの解析 要求メトリックのトレース・レコードは、Web サーバー・プラグイン・ログ・ファイル（httpd_plugin.log）とア プリケーション・サーバーの標準出力ログ・ファイル（SystemOut.log）に出力されます。 以下に出力例を示します。 http_plugin.log [Sat Dec 13 17:36:52 2008] 00080008 00000708 PLUGIN: parent:ver=1,ip=9.188.198.75,time=1229157377533,pid=524296,reqid=1,event=1 current:ver=1,ip=9.188.198.75,time=1229157377533,pid=524296,reqid=1,event=1 type=HTTP detail=/TestConnectDBWeb/SampleServlet elapsed=5678 bytesIn=0 bytesOut=0 ログでは１メソッドの呼び出しに関するデータが１レコードに記録されています。レコードごとに parent （親）と current（子）で構成されており、parent ではメソッドの呼び出し元のデータが、current では呼び出 された側のデータが記録されます。 以下に、サーブレットから JDBC 接続でデータベースへアクセスするサンプル・アプリケーション 「SampleServlet」を実行した際に、要求メトリックが出力するデータの例を示します。 http_plugin.log [Sat Dec 13 17:42:42 2008] 000ad0b2 00000203 - PLUGIN: parent:ver=1,ip=9.188.198.75,time=1229157750922,pid=708786,reqid=2,event=1 current:ver=1,ip=9.188.198.75,time=1229157750922,pid=708786,reqid=2,event=1 type=HTTP detail=/TestConnectDBWeb/SampleServlet elapsed=136 bytesIn=0 bytesOut=0 レスポンスタイム 自分のリクエストID 136ミリ秒 2 親のリクエストID 自分のリクエストID 10 10 親のリクエストID SystemOut.log 2 [08/12/13 17:42:42:312 JST] 00000022 PmiRmArmWrapp I PMRM0003I: parent:ver=1,ip=9.188.198.75,time=1229157192943,pid=692402,reqid=10,event=1 current:ver=1,ip=9.188.198.75,time=1229157192943,pid=692402,reqid=14,event=1 type=JDBC detail=java.sql.Statement.executeQuery(String) elapsed=2 レスポンスタイム [08/12/13 17:42:42:368 JST] 00000022 PmiRmArmWrapp I PMRM0003I: 2ミリ秒 parent:ver=1,ip=9.188.198.75,time=1229157750922,pid=708786,reqid=2,event=1 current:ver=1,ip=9.188.198.75,time=1229157192943,pid=692402,reqid=10,event=1 type=URI detail=/TestConnectDBWeb/SampleServlet elapsed=112 レスポンスタイム 112ミリ秒 Web サーバー・プラグインのログには「type=HTTP」のデータ、server1 のログには「type=URI」と 「type=JDBC」のデータが表示されています。 まず、Web サーバー・プラグインのログを見ると、/TestConnectDBWeb/SampleServlet にアクセスがあ り 、 こ の と き に 付 加 さ れ た ID が 「 2 」 で す 。 次 に 。 server1 の ロ グ を 見 る と 、 reqid=2 か ら /TestConnectDBWeb/SampleServlet にアクセスがあり、このときに付加された ID が「10」です。reqid=10 から SQL が呼び出され DB にアクセスしていることがわかります。このようにして、parent データの reqid と current データの reqid によって、１リクエストの複数オペレーションを紐付けることができます。下図に 示すように、elapsed によってレスポンス・タイムも出力されているので、各コンポーネントの処理時間を解 析することができます。 レコードに記録されている、ログ・フォーマットの各フィールドの意味は以下の通りになります。 フィールド parent current ver ip pid time reqid event type detail elapsed bytesIn bytesOut 説明 呼び出し側（親）の識別子 呼び出された側（子）の識別子 親と子の相関関係のバージョン。親子の両者は同じ数字になります。 アプリケーション・サーバーがあるノードの IP アドレス アプリケーション・サーバーのプロセス ID アプリケーション・サーバーのプロセス開始時刻 要求メトリックによってリクエストに割り当てられる ID 実際のトレースを区別するために割り当てられるイベント ID リ ク エ ス ト の タ イ プ で 、 HTTP 、 URI 、 EJB 、 JDBC 、 JMS 、 非 同 期 ビ ー ン （COMMONJ_WORK_POOLED、COMMONJ_TIMER）、Web サービス（要求者、プロバ イダー）がサポートされています。 リクエストの詳細データで、URI のフルパス、SQL ステートメント、EJB メソッド名などになり ます。 トータルの経過時間（ミリ秒）で、子の経過時間を全て含んだ時間です。 Web サーバー・プラグインが受け取ったリクエストのバイト数 Web サーバー・プラグインからクライアントに送信されたレスポンスのバイト数 type フィールドおよび detail フィールドの説明は以下の通りです。 フィールド HTTP URI 説明 Web サーバー・プラグインが生成するトレース・レコードです。detail では、リクエストを呼 び出すとき使用される URI が記録されます。 Web コンポーネントが生成するトレース・レコードです。detail では、リクエストを呼びだ EJB JDBC JMS 非同期 Bean Web サービス す時に使用される URI が記録されます。 Enterprise Bean の完全修飾パッケージおよびメソッド名です。 作成済みステートメントの select,update,insert,delete 値。作成されていないステートメント の場合は、完全なステートメントが表示されることがあります。 JMS パラメーターの詳細が含まれます。 非 同 期 Bean の 名 前 を 指 定 す る 詳 細 。 非 同 期 ビ ー ン に は 2 つ の タ イ プ 、 COMMONJ_WORK_POOLED および COMMONJ_TIMER が含まれています。 Web サービス・パラメーターの詳細が含まれています。 3-4-5 verbosegc verbosegc ログは JVM によるガーベッジ・コレクションが実施された際の詳細な実施結果を取得するこ とのできるログです。例えば、コレクションの実施頻度や各コレクションの所要時間、開放されたヒープ領 域の大きさなどがわかりますので、問題判別時のガーベッジ・コレクションの挙動調査にも使われます。 3-4-5-1 verbosegc の設定方法 verbosegc を有効にするには JVM に-verbosegc オプションを設定します。管理コンソールから設定が 可能です。管理コンソールのナビゲーション・ツリーより[サーバー]→[サーバー・タイプ]→[WebSphere Application Server]→[ApplicationServer_name]→[サーバー・インフラストラクチャー]→[Java および プロセス管理]→[プロセス定義]→[追加プロパティー]→[Java 仮想マシン] を選択し、Java 仮想マシン の設定ページを表示します。このページに冗長ガーベッジ・コレクションのチェックボックスがあります。こ こにチェックを付けると次回アプリケーション･サーバーが始動するタイミングから verbosegc ログが出力さ れるようになります。デフォルトの出力先は<WAS_root>/profiles/<profile_name>/logs/native_stderr.log です。 verbosegc ログは JVM 汎用引数[-verbosegc]を入れることでも取得が可能です。設定後はアプリケー ション・サーバーの再起動が必要になります。 また、-Xverbosegclog オプションを指定することによって出力先ファイルを明示的に指定することも可能 です。 図 3-68 Java 仮想マシン設定 3-4-5-2 verbosegc の出力内容 3-3-4-7「Java ヒープサイズのチューニング」の項目で説明したように、ガーベッジ･コレクションには領 域の観点から整理すると Scavenger と Global の二つのタイプがあります。Generational Concurrent 以外 の GC ポリシーでは Global コレクションにて実施されます。さらに実施タイミングの観点から Global 領域 におけるコレクションには Optimize for Pause Time、また Generational Concurrent のアルゴリズムを適用 した際には Concurrent コレクションが実施されます。Concurrent コレクションは Generational Concurrent 適用時の Tenured 領域でも実施されます。整理すると下図のようにまとめることができます。 GC ポリシー コレクション方法 Global Optimize for Throughput Concurrent および Global Optimize for Pause Time Global Subpooling Generational Concurrent Scavenger ( Nursery 領域) Concurrent および Global (Tenured 領域) 表 3-69 各 GC ポリシーで実施されるコレクション形態 ここでは Concurrent コレクションを含めた 3 種類のコレクションが実施された際の出力内容について見て いくことにします。 Global コレクション まずはデフォルト GC ポリシーである Optimize for Throughput の出力例を見ていくことにします。 Subpooling ポリシーを適用している場合も同じガーベッジ･コレクションのアルゴリズムを使用しているの で同じ出力形態をとります。 <af type="tenured" id="25" timestamp="Dec 13 21:03:39 2008" intervalms="2029.810"> <minimum requested_bytes="8216" /> <time exclusiveaccessms="0.048" meanexclusiveaccessms="0.048" threads="0" lastthreadtid= "0x31CFE500" /> <refs soft="622" weak="10910" phantom="35" dynamicSoftReferenceThreshold="13" maxSoftReferenceThreshold="32" /> <tenured freebytes="524288" totalbytes="52428800" percent="1" > <soa freebytes="0" totalbytes="51904512" percent="0" /> <loa freebytes="524288" totalbytes="524288" percent="100" /> </tenured> <gc type="global" id="27" totalid="27" intervalms="2030.296"> <classunloading classloaders="0" classes="0" timevmquiescems="0.000" timetakenms="2.421" /> <finalization objectsqueued="63" /> <timesms mark="88.282" sweep="0.929" compact="0.000" total="91.785" /> <tenured freebytes="19388048" totalbytes="52428800" percent="36" > <soa freebytes="18916496" totalbytes="51957248" percent="36" /> <loa freebytes="471552" totalbytes="471552" percent="100" /> </tenured> </gc> <tenured freebytes="19379832" totalbytes="52428800" percent="36" > <soa freebytes="18908280" totalbytes="51957248" percent="36" /> <loa freebytes="471552" totalbytes="471552" percent="100" /> </tenured> <refs soft="622" weak="10886" phantom="35" dynamicSoftReferenceThreshold="11" maxSoftReferenceThreshold="32" /> <time totalms="92.189" /> </af> 図 3-70 verbosegc ログ出力例（Global コレクション） それぞれの出力内容の意味について説明していきます。 ガーベッジ・コレクションの開始はトリガーとなる Allocation Failure の発生を示す<af>タグにより始まりま す。 <af type="tenured" id="25" timestamp="Dec 13 21:03:39 2008" intervalms="2029.810"> --- 途中省略 --</af> <af>タグから Allocation Failure についての詳細情報が取得できます。type 属性から Allocation Failure がどの領域で発生したかがわかります。Global コレクションでは type 属性の値は tenured となります。な お、Generational Concurrent における Nursery 領域以外で Allocation Failure が発生した場合、つまり Global コレクションが実施される場合は適用されている GC ポリシーの種類に関わらずすべて tenured と 出力されます（言い換えると世代管理を行わない領域を Tenured 領域と定義できます）。Id 属性はコレク ション番号、timestamp では Allocation Failure の発生時間、intervalms 属性では前回の Allocation Failure からの経過時間がそれぞれ記録されます。 <minimum requested_bytes="8216" /> <time exclusiveaccessms="0.048" meanexclusiveaccessms="0.048" threads="0" lastthreadtid= "0x31CFE500" /> <af>タグの後にはヒープ割り当てに失敗したオブジェクトのサイズ（minimum requested_bytes）と、JVM の ST コンポーネントがガーベッジ・コレクションを実施するために各種スレッドを停止させるためのロック を取得して JVM の制御を取得するのに要した時間（time exclusiveaccessms）が出力されます。 <tenured freebytes="524288" totalbytes="52428800" percent="1" > <soa freebytes="0" totalbytes="51904512" percent="0" /> <loa freebytes="524288" totalbytes="524288" percent="100" /> </tenured> <tenured>タグには Allocation Failure 時のヒープの空き容量、およびヒープサイズが出力されます。ここ での出力は soa と loa の領域の和になります。なお、soa は Small object area(通常のオブジェクトを格納 する領域：Large object area 以外の場所)、loa は Large object area のことを示します。 もしこの部分の出力結果から、十分大きな空き領域があるにもかかわらず小さいサイズのオブジェクトの 割り当てに失敗していることが判明した場合は、メモリーの分断化（Fragmentation）が発生している可能 性があります。 <gc type="global" id="27" totalid="27" intervalms="2030.296"> <classunloading classloaders="0" classes="0" timevmquiescems="0.000" timetakenms="2.421" /> <finalization objectsqueued="63" /> <timesms mark="88.282" sweep="0.929" compact="0.000" total="91.785" /> <tenured freebytes="19388048" totalbytes="52428800" percent="36" > <soa freebytes="18916496" totalbytes="51957248" percent="36" /> <loa freebytes="471552" totalbytes="471552" percent="100" /> </tenured> </gc> --- 途中省略 --<time totalms="92.189" /> 次に来るのが<gc>タグです。ここから実際のガーベッジ・コレクションによるヒープ開放の結果が出力さ れています。<finalization>タグには finalize 処理が実施されるのを待っているオブジェクトの総数が出力 されます。<timesms>タグを見ると、Mark、Sweep、Compaction の各フェーズにそれぞれ要した時間を確 認することができます。また実際にどれくらいのヒープが開放されたかが<tenured>タグで挟まれている 部分に出力されます。 出力の最後には Allocation Failure が発生してからガーベッジ･コレクションが実施され、各種コントロー ルが Allocation Failure 発生直後の各スレッドに戻されて処理が再開されるまでに要した時間が出力さ れます。 Scavenger コレクション Scavenger コレクションは Generational Concurrent ポリシーを適用した時にのみ発生します。発生のトリ ガーは Nursery 領域にて Allocation Failure が発生することです。Global コレクション、Scavenger コレク ションではオブジェクトの世代管理が行われるため、Global コレクション適用時の verbosegc ログの出力 内容と比較すると Survivor および Tenured 領域へのオブジェクトコピー結果と Nursery および Tenured 領域毎のヒープ利用状況/開放結果が加わります。 <af type="nursery" id="46" timestamp="Dec 13 21:31:03 2008" intervalms="1473.116"> <minimum requested_bytes="16672" /> <time exclusiveaccessms="0.073" meanexclusiveaccessms="0.073" threads="0" lastthreadtid= "0x3664DF00" /> <refs soft="4601" weak="11312" phantom="58" dynamicSoftReferenceThreshold="14" maxSoftReferenceThreshold="32" /> <nursery freebytes="0" totalbytes="20298240" percent="0" /> <tenured freebytes="6383832" totalbytes="39321600" percent="16" > <soa freebytes="4417752" totalbytes="37355520" percent="11" /> <loa freebytes="1966080" totalbytes="1966080" percent="100" /> </tenured> <gc type="scavenger" id="46" totalid="48" intervalms="1473.282"> <failed type="flipped" objectcount="14857" bytes="596008" /> <flipped objectcount="107441" bytes="6033136" /> <tenured objectcount="14857" bytes="563328" /> <finalization objectsqueued="18" /> <scavenger tiltratio="67" /> <nursery freebytes="11580416" totalbytes="18081280" percent="64" tenureage="14" /> <tenured freebytes="5597400" totalbytes="39321600" percent="14" > <soa freebytes="3631320" totalbytes="37355520" percent="9" /> <loa freebytes="1966080" totalbytes="1966080" percent="100" /> </tenured> <time totalms="22.856" /> </gc> <nursery freebytes="11563744" totalbytes="18081280" percent="63" /> <tenured freebytes="5597400" totalbytes="39321600" percent="14" > <soa freebytes="3631320" totalbytes="37355520" percent="9" /> <loa freebytes="1966080" totalbytes="1966080" percent="100" /> </tenured> <refs soft="4578" weak="11089" phantom="58" dynamicSoftReferenceThreshold="14" maxSoftReferenceThreshold="32" /> <time totalms="23.114" /> </af> 図 3-71 verbosegc ログ出力例（Scavenger コレクション） Global コレクションの出力と同様に、ガーベッジ・コレクションの開始はトリガーとなる Allocation Failure の発生を示す<af>タグにより始まります。違いは type 属性が Scagenger コレクションの実施場所を示す nursery となっている点です。 <af type="nursery" id="46" timestamp="Dec 13 21:31:03 2008" intervalms="1473.116"> <minimum requested_bytes="16672" /> <time exclusiveaccessms="0.073" meanexclusiveaccessms="0.073" threads="0" lastthreadtid= "0x3664DF00" /> <refs soft="4601" weak="11312" phantom="58" dynamicSoftReferenceThreshold="14" maxSoftReferenceThreshold="32" /> <nursery freebytes="0" totalbytes="20298240" percent="0" /> <tenured freebytes="6383832" totalbytes="39321600" percent="16" > <soa freebytes="4417752" totalbytes="37355520" percent="11" /> <loa freebytes="1966080" totalbytes="1966080" percent="100" /> </tenured> --- 途中省略 --</af> <af>タグに引き続いて出力される内容はヒープ状態を示す情報が Nursery と Tenured 領域に分かれて 表示されている他は Globaｌコレクションと同じです。出力されている Nursery 領域の大きさは実際には Allocation 領域の大きさを示しています。そのため、実際に確保されている Nursery 領域に Tiloratio を 掛け合わせた値が表示されます。このときに適用されている Tiloratio はひとつ前のガーベッジ･コレクシ ョンにて決定されたものです。Scavenge コレクションが実施されるたびに Tiltratio が動的に決定され、そ の値に基づいて Allocate 領域と Survivor 領域の大きさが定義されます。 <gc type="scavenger" id="46" totalid="48" intervalms="1473.282"> <failed type="flipped" objectcount="14857" bytes="596008" /> <flipped objectcount="107441" bytes="6033136" /> <tenured objectcount="14857" bytes="563328" /> <finalization objectsqueued="18" /> <scavenger tiltratio="67" /> --- 途中省略 --</gc> Allocation Failure についての結果に引き続いてガーベッジ･コレクションの実施結果について出力され ます。Scavenger コレクションでは Allocate 領域から Survivor 領域にコピーされたオブジェクトの数と総サ イズが<flipped>タグの出力から、Allocate 領域から Tenured 領域にコピーされたオブジェクトについての 情報を<tenured>タグの出力から取得することができます。またこのガーベッジ・コレクションの実施結果 に従って算出された Tiloratio の値が出力されます（scavenger tiltratio="67"）。 Concurrent コレクション 最後に Concurrent コレクションの出力について説明します。Concurrent コレクションは Optimize for Pause Time ポリシーまたは Generational Concurrent ポリシーを適用した場合の tenured 領域にて行われ ます。 <con event="kickoff" timestamp="Dec 13 21:41:45 2008"> <kickoff reason="Kickoff threshold reached" /> <stats tenurefreebytes="2763544" tracetarget="18761792" kickoff="2573086" /> </con> <con event="collection" id="21" timestamp="Dec 13 21:41:45 2008" intervalms="2789.674"> <time exclusiveaccessms="0.068" meanexclusiveaccessms="0.068" threads="0" lastthreadtid= "0x33A4E800" /> <refs soft="2175" weak="12138" phantom="87" dynamicSoftReferenceThreshold="13" maxSoftReferenceThreshold="32" /> <tenured freebytes="2616936" totalbytes="52428800" percent="4" > <soa freebytes="2423632" totalbytes="52062208" percent="4" /> <loa freebytes="193304" totalbytes="366592" percent="52" /> </tenured> <stats tracetarget="18761792"> <traced total="19494824" mutators="18632" helpers="19476192" percent="103" /> <cards cleaned="80" kickoff="1013639" reason="tracing completed" /> </stats> <con event="completed full sweep" timestamp="Dec 13 21:41:45 2008"> <stats sweepbytes="0" sweeptime="0.043" connectbytes="6291456" connecttime="0.006" /> </con> <con event="final card cleaning"> <stats cardscleaned="1" traced="0" durationms="0.106" /> </con> <gc type="global" id="31" totalid="31" intervalms="2790.815"> <classunloading classloaders="0" classes="0" timevmquiescems="0.000" timetakenms="2.449" /> <finalization objectsqueued="27" /> <timesms mark="34.781" sweep="0.145" compact="0.000" total="37.539" /> <tenured freebytes="20450560" totalbytes="52428800" percent="39" > <soa freebytes="20255072" totalbytes="52114432" percent="38" /> <loa freebytes="195488" totalbytes="314368" percent="62" /> </tenured> </gc> <tenured freebytes="20450560" totalbytes="52428800" percent="39" > <soa freebytes="20255072" totalbytes="52114432" percent="38" /> <loa freebytes="195488" totalbytes="314368" percent="62" /> </tenured> <refs soft="2089" weak="11298" phantom="87" dynamicSoftReferenceThreshold="12" maxSoftReferenceThreshold="32" /> <time totalms="38.817" /> </con> 図 3-72 verbosegc ログ出力例（Concurrent コレクション） Concurrent フェーズの始まりは以下の出力で確認できます。 <con event="kickoff" timestamp="Dec 13 21:41:45 2008"> <kickoff reason="Kickoff threshold reached" /> <stats tenurefreebytes="2763544" tracetarget="18761792" kickoff="2573086" /> </con> この出力は Concurrent フェーズが timestamp 属性で表されている時間に開始（kickoff）したことを示して います。<stats>タグにはその時の Tenured 領域の空き領域、Concurrent フェーズにおけるアプリケーショ ン・スレッドのトレース目標、そして Concurrent フェーズ開始のトリガーとなる kickoff 閾値が出力されま す。 <con event="collection" id="21" timestamp="Dec 13 21:41:45 2008" intervalms="2789.674"> <time exclusiveaccessms="0.068" meanexclusiveaccessms="0.068" threads="0" lastthreadtid= "0x33A4E800" /> <refs soft="2175" weak="12138" phantom="87" dynamicSoftReferenceThreshold="13" maxSoftReferenceThreshold="32" /> <tenured freebytes="2616936" totalbytes="52428800" percent="4" > <soa freebytes="2423632" totalbytes="52062208" percent="4" /> <loa freebytes="193304" totalbytes="366592" percent="52" /> </tenured> <stats tracetarget="18761792"> <traced total="19494824" mutators="18632" helpers="19476192" percent="103" /> <cards cleaned="80" kickoff="1013639" reason="tracing completed" /> </stats> --- 途中省略 --</con> Concurrent トレースが終了し、トレース後に変更された領域の再スキャンも終了すると Concurrent コレク ション(event=”concurrent”)を開始します。<stats>タグには Concurrent Mark 処理の実施結果が出力され ます。mutetors 属性の値はアプリケーション(ミューテーターと呼ばれます)がトレースした結果、helpers 属性ではバックエンドで起動されていたスレッドの実施結果をそれぞれ確認できます。また、再スキャン を行う際にヒープを複数の領域に分割して実施するのですが、その分割された領域をカードと呼ばれ、 Concurrent Mark 中にスキャンされたカード情報が出力されています。 <con event="completed full sweep" timestamp="Dec 13 21:41:45 2008"> <stats sweepbytes="0" sweeptime="0.043" connectbytes="6291456" connecttime="0.006" /> </con> Concurrent Mark の実施結果の次に出力されているのは Concurrent コレクションフェーズにおける Sweep 処理の結果です。これに引き続いて以下のカードの再スキャン結果が出力されます。この再スキ ャンによって Concurrent トレース中にやり残した部分がすべて処理されます。 <con event="final card cleaning"> <stats cardscleaned="1" traced="0" durationms="0.106" /> </con> 上記で説明した一連の Concurrent フェーズが終了した後に、通常の Global コレクションが実施されま す。Concurrent フェーズによって部分的にガーベッジ・コレクション処理が事前に行われることで、Global コレクションに要する時間が短縮されます。 （参考）Concurrent フェーズが終わらないうちに Allocation Failure が発生した場合 Concurrent フェーズによって事前処理が行われている最中に Global コレクションがトリガーされてしまう ケースもあります。その場合、ST コンポーネントは Concurrent フェーズの途中結果を破棄するか、結果 を Global コレクションの一部に組み入れるかのいずれかの動きをとります。どちらの行動を選択したかは verbosegc ログの中の<con >タグで”aborted”となっているか”halted”となっているかで判断できます。