10

10 パフォーマンス管理 ............................................................................................................... 3
10-1 パフォーマンス .................................................................................................................... 3
10-1-1 パフォーマンスの指標 ..................................................................................................... 3
10-1-2 スループット ..................................................................................................................... 4
10-1-3 応答時間.......................................................................................................................... 4
10-2 チューニング ....................................................................................................................... 6
10-2-1 キューイング・ネットワーク .............................................................................................. 6
10-2-1-1 キューイング・ネットワーク .......................................................................................... 6
10-2-1-2 WAS におけるパラメーター設定 ............................................................................... 11
10-2-2 W EB サーバー................................................................................................................ 14
10-2-2-1 IBM HTTP Server のリクエスト処理方法 ................................................................ 14
10-2-2-2 IBM HTTP Server のモニタリング ............................................................................ 16
10-2-3 データベース接続.......................................................................................................... 17
10-2-3-1 接続プール・サイズ ................................................................................................... 17
10-2-3-2 Prepared Statement Cache サイズ ........................................................................ 17
10-2-4 JVM ................................................................................................................................ 19
10-2-4-1 JVM のチューニング .................................................................................................. 19
10-2-4-2 GC ポリシー ............................................................................................................... 21
10-2-4-3 Optimize for Throughput (-Xgcpolicy:optthruput) ................................................ 22
10-2-4-4 Optimize for Pause Time (-Xgcpolicy:optavgpause) ........................................... 24
10-2-4-5 Generational Concurrent (-Xgcpolicy:gencon)..................................................... 25
10-2-4-6 Balanced (-Xgcpolicy:balanced) ............................................................................ 29
10-2-4-7 Java ヒープ・サイズのチューニング ......................................................................... 30
10-2-4-8 Java ヒープ・サイズの設定........................................................................................ 35
10-2-4-9 V7.0 以降での JVM ランタイムの改良点 ................................................................. 35
10-2-4-10 共有クラスキャッシュ............................................................................................... 36
10-2-4-11 共有クラスキャッシュの設定 ................................................................................... 36
10-2-4-12 参照の圧縮 (Compressed references) .............................................................. 37
10-2-4-13 参照の圧縮の有効化.............................................................................................. 37
10-2-4-14 ランタイム・プロビジョニング ................................................................................... 37
10-2-4-15 ランタイム・プロビジョニングの有効化 ................................................................... 38
10-3 モニタリング・ツール ......................................................................................................... 39
10-3-1 PERFORMANCE MONITORING INFRASTRUCTURE ......................................................... 39
10-3-1-1 概要............................................................................................................................ 39
10-3-1-2 モニターできるデータ ................................................................................................ 40
10-3-1-3 PMI 設定 .................................................................................................................... 41
10-3-2 TIVOLI PERFORMANCE VIEWER..................................................................................... 42
10-3-2-1 モニターの開始.......................................................................................................... 42
10-3-2-2 ユーザー設定およびロギング設定 ........................................................................... 42
10-3-2-3 現行アクティビティの表示（パフォーマンス・モジュール） ........................................ 44
10-3-2-4 モニタリング・ポイント ................................................................................................ 46
10-3-2-5 ロギング ..................................................................................................................... 51
10-3-3 パフォーマンス・アドバイザー ....................................................................................... 53
10-3-4 要求メトリック ................................................................................................................. 55
10-3-4-1 基本使用方法 ............................................................................................................ 56
10-3-4-2 トレース・レベルの設定 ............................................................................................. 57
10-3-4-3 フィルターの設定 ....................................................................................................... 58
10-3-4-4 ログの解析 ................................................................................................................ 59
10-3-5 VERBOSE:GC................................................................................................................... 61
10-3-5-1 verbose:gc の設定方法 ............................................................................................ 61
10-3-5-2 verbose:gc の出力内容 ............................................................................................ 62
10-3-6 INTELLIGENT MANAGEMENT 機能によるモニタリング .................................................. 69
10-3-6-1 レポート機能 .............................................................................................................. 69
10-3-6-2 オペレーション・アラート ............................................................................................ 70
10-3-6-3 ランタイム・タスク ....................................................................................................... 71
10-3-6-4 可視化データ・サービス ............................................................................................ 71
10-4 動的キャッシュ .................................................................................................................. 72
10-4-1 キャッシュされるコンテンツ ........................................................................................... 72
10-4-2 動的キャッシュ・サービス .............................................................................................. 73
10-4-3 キャッシュのロケーション .............................................................................................. 75
10-4-4 キャッシュ・インスタンス ................................................................................................ 76
10-4-5 キャッシュの複製 ........................................................................................................... 77
10-4-6 キャッシュの無効化 ....................................................................................................... 77
10-4-7 ディスク・オフロード ....................................................................................................... 78
10-4-8 CACHESPEC.XML ファイル .............................................................................................. 78
10-4-9 動的キャッシュの設定 ................................................................................................... 79
10-4-9-1 動的キャッシュ・サービスの有効化 .......................................................................... 79
10-4-9-2 キャッシュ・インスタンスの作成 ................................................................................ 80
10-4-9-3 サーブレット・キャッシングの設定 ............................................................................. 81
10-4-9-4 ポートレット・キャッシングの設定 .............................................................................. 83
10-4-9-5 キャッシュ・サイズの設定 .......................................................................................... 83
10-4-9-6 ディスク・オフロードの設定 ....................................................................................... 84
10-4-9-7 ディスク・オフロードのチューニング .......................................................................... 87
10-4-9-8 キャッシュの複製 ....................................................................................................... 88
10-4-9-9 cachespec.xml によるキャッシュ・ポリシーの定義................................................. 90
10-4-9-10 cachespec.xml 記述例 ........................................................................................... 95
10-4-9-11 動的キャッシュの管理 ............................................................................................. 98
10-4-9-12 外部キャッシュ....................................................................................................... 103
10-4-9-13 外部キャッシュの設定 ........................................................................................... 103
10 パフォーマンス管理
この章では、WAS を使用した Web システムにおいてパフォーマンスを向上させるための考慮点につ
いて説明します。
10-1 ではパフォーマンスを計測する際の代表的な指標としてスループットと応答時間について説明し
ます。10-2 ではパフォーマンスを向上させるためのパフォーマンス・チューニングを、10-3 ではチューニ
ングを目的としたモニタリングの方法について説明します。10-4 では、パフォーマンス向上のために
WAS で提供されている機能として動的キャッシュについて説明します。チューニング方法については一
般論を紹介しており、各パラメーターの最適値は実際の環境およびアプリケーションによって異なります
のでご注意下さい。
10-1 パフォーマンス
この節では Web システムにおけるパフォーマンスの代表的な指標としてスループットと応答時間（レス
ポンス・タイム）の２つについての一般的な考え方について説明します。
10-1-1 パフォーマンスの指標
Web システムにおけるパフォーマンスの代表的な指標はスループットと応答時間によって測られま
す。以下、それぞれについて説明します。
•
スループット：単位時間（秒）あたりにシステムによって処理されるリクエスト数です。ユーザーからの
リクエストを一度にどれだけ処理できるかを表す値であり、システム全体の処理能力を表していま
す。
•
応答時間：ユーザーがリクエストを出してから、すべての結果が戻るまでの時間でユーザーから見
た処理能力になります。どれだけスループットが大きくても、各々のユーザーにとって応答時間が
重要な点に注意しなくてはなりません。システムの負荷を判断する指標になり得ます。
システムの性能評価を行う際、横軸を同時ユーザー数、縦軸をスループットとしてプロットしたスループ
ットのグラフや、横軸を同時ユーザー数、縦軸を応答時間としてプロットした応答時間のグラフを作成し
て分析を行っていきます。
10-1-2 スループット
図 10-1 では Web システムにおいて、同時アクセス数の増加に応じたスループットの変化の典型的な
パターンを一例として示しています。アプリケーションやシステムの設定でボトルネックを除去した状態が
前提です。データの推移によって、A ゾーン、Ｂゾーン、Ｃゾーンに分けて、それぞれのゾーンでシステ
ムがどのような状態であるかを知ることができます。
図 10-1 スループット
•
A ゾーン：同時アクセス数の増加に伴い、スループットは増加します。この段階では、システムはす
べてのリクエストを滞留させることなく処理できている状態といえます。
•
B ゾーン：CPU が 100%に達した後も同時アクセスを増加させると応答時間は悪化しますが、スルー
プットは増加します。同時アクセス数がシステムの許容量（飽和点）を超えると、スループットはそれ
以上伸びなくなり、落ち始めます。
•
C ゾーン：飽和点をさらに超えると、スループットは落ち始め、Web システムとしては不健全な状態と
なります。これはあまりにもアクセス数が多すぎるため、ネットワーク資源の競合やページング等が
頻発し、本来のシステムの能力が発揮できなくなった状態です。
CPU 使用率が低いにも関わらず、スループットが飽和点に達する場合、システムの能力を活用できて
いません。他の要因がボトルネックになっている可能性があるので、ボトルネックを追及して解消する必
要があります。
想定される同時アクセス数に対して、A ゾーンまたは B ゾーンの範囲でシステムが稼動するように、チュ
ーニングを行います。
10-1-3 応答時間
図 10-2 では、Web システムにおいて、同時アクセス数の増加に応じた応答時間の変化のパターンを示
しています。
図 10-2 応答時間
一般に、システムに対するリクエスト数が増加すると、システムに余力のある場合は応答時間に大きな
変化はありません。
リクエスト数がシステムの処理能力を超えると応答時間は急速に悪化します。その場合でも、システムが
適切にチューニングされていれば、処理しきれないリクエストはエラーで戻すなどの処理によって、応答
時間は一定の限度内に収めることができます。チューニングが不適切な場合は、いつまで待っても応答
が戻らないような事態も発生し得ます。
想定されるリクエスト数に対して、充分なスループットを持つシステムを設計する必要があると同時に、
要件を満たす応答時間を実現するようにパフォーマンス・チューニングを行う必要があります。
システムの能力を充分に活用し、適切なスループットと応答時間を得るためには、パフォーマンス・チュ
ーニングを欠かすことはできません。
10-2 チューニング
この節では、パフォーマンスを向上させるためのパラメーター・チューニングについて説明します。
WAS でチューニングを考慮する際の基本的なポイントはキューイング・ネットワークと JVM メモリーのチ
ューニングになります。キューイング・ネットワークのチューニングでは WAS だけではなく Web サーバー
も考慮する必要があります。Web サーバーのチューニングについては 10-2-2Web サーバー(p.14)で説
明します。
10-2-1 キューイング・ネットワーク
キューイング・ネットワークの考え方とチューニングで設定する WAS の各コンポーネントのパラメータ
ーについて説明します。
10-2-1-1 キューイング・ネットワーク
Web アプリケーションにおいては、クライアントからのリクエストはランダムにサーバーに到達し、サー
バーが一度に受け取るリクエスト数は非常に波があるのが通常です。また、システムには許容量があり、
ある程度を超えたリクエストを同時に処理しようとすると、システム本来の性能が発揮できない可能性が
あります。このため、WAS ではリクエストが Web サーバー、アプリケーション・サーバー、データベースを
流れる際に、各々のコンポーネントの入り口で一度に処理するリクエストの数を制限します。処理しきれ
ない分は行列に並ばせ、順番に受け付けます。このときの待ち行列を「キュー」と呼び、待ち行列による
リクエスト管理を「キューイング」と呼びます。サーバーは、一定限度までのリクエストは並行に処理します
が、システムに設定された数を超えた同時リクエストは、キューに入れられ、処理の順番を待ちます。
同時リクエスト数が非常に多く、キューの中での待機時間が長くなって、キューへの送信側で設定さ
れたタイムアウト値を超えた場合は、クライアントにエラーとして戻されます。システムの許容量を超えたリ
クエストがあった場合に、ユーザーのストレスを軽減し、システムの負荷を必要以上に大きくしないため
には適切なタイムアウトの設定も重要です。
キューには、オープン・キューとクローズド・キューの２種類があります。
•
オープン・キュー
キューの中で活動状態にあるリクエスト数に制限はありません。
•
クローズド・キュー
キューの中で活動状態にあるリクエスト数に上限があり、システムによってリソースへの同時アクセ
スが管理されています。クローズド・キューの中のリクエストは、活動状態か待ち状態のいずれかの
状態となります。活動状態とは、このリクエストが対象のコンポーネントによって現在実行中である
か、更に先のコンポーネントによる処理の終了待ち状態である場合をいいます。待ち状態とは、こ
のリクエストが対象のコンポーネントによる実行待ちである場合をいいます。
アプリケーション・サーバーに対するサーブレットの実行要求は複数のコンポーネントによって順番に
処理が行われていきます。以下の図に一連の処理の例を示します。ブラウザーからのリクエストはネット
ワークを経由して、Web サーバーで受け付けられます。Web サーバーの処理を経て、WAS のコンポー
ネントである Web コンテナーと EJB コンテナーで処理され、データ・ソースを使用したデータベース接続
の処理が行われます。Web サーバー、Web コンテナー、EJB コンテナー、データ・ソースの各コンポーネ
ントにはそれぞれキューが存在し、この一連のキューのつながりをキューイング・ネットワークと呼びま
す。各々のキューはクローズド・キューであり、同時に実行可能なリクエスト数に制限があります。
図 10-3 キューイング・ネットワーク
•
Web サーバーのキュー
•
Web コンテナーのキュー（オープン・キューとしても構成可能）
•
EJB コンテナーのキュー（オープン・キューとしても構成可能）
•
データ・ソースのキュー
パラメーター調整の原則
キューの中で活動状態にあるリクエスト（スレッド）の最大数を各コンポーネントのパラメーターで設定す
ることが可能です。
同時に実行可能なスレッド数を増やすことによって、ある程度はスループットの向上が望めますが、その
数はコンポーネントが稼動するマシンの能力に依存するものです。過剰なスレッドの実行はメモリーなど
のリソースを必要以上に消費し、パフォーマンスの低下を招くことになります。
それぞれのパラメーターを調整して、各コンポーネントで過剰なスレッドが実行されることのない最適値
を見い出します。
各コンポーネントの一連の処理が、シームレスに処理される環境であれば各コンポーネントで設定す
るパラメーターは同じ数になりますが、実際は各コンポーネントで処理可能なスレッド数は異なり、キュー
で待ちが発生することになります。
一般的には、ネットワーク側（Web サーバーの手前）で処理を待つリクエストの数を多く、アプリケーシ
ョン・サーバー内部で処理を待つリクエストの数が小さくなるように調整します。リクエストの待機は、その
コンポーネントへの負荷が発生するので、リクエストをできるだけネットワーク側で待たせることによってア
プリケーション・サーバーへの負荷を軽減することができます。ネットワーク側でリクエストを待機させるこ
とができない場合は、アプリケーション・サーバー側で待機させることになります。
また、バックエンド側のスレッド数を増やしたい場合は、その前段のコンポーネントのスレッド数も増加
させて多くのリクエストを受け付けるようにする必要があります。
図 10-4 にパラメーター調整の一例を示します。クライアントから同時に到着した要求数 200 に対し、
Web サーバーへの接続待ちが 125、Web コンテナーの接続待ち、データベース（データ・ソース）への接
続待ちがそれぞれ 25 となっています。
図 10-4 パラメーター調整
理想的には、システムの負荷テストを行った上で、それぞれのキューの最大数に達したときにシステム
の CPU の使用率が 100%となり、システムの最大のパフォーマンスが得られるように、パラメーターを設
定するのが良いでしょう。
アプリケーションの構成によっても、キューのパラメーターを調整する必要があります。具体的には以
下の例があてはまります。
•
ほとんどのページが静的コンテンツ（HTML ファイルなど）で構成され、クライアントからの要求のう
ちサーブレットの実行を必要とするものが少ないサイトの場合、HTTP サーバーのキューのサイズを
特に大きくする必要があります。
•
サーブレット内部での複雑な処理に CPU の 90%、データベース接続を使用した簡単な処理に残り
の 10%を使用しているアプリケーションの場合、平均すれば同時実行中のサーブレットのうち 10%
のみがデータベースに同時に接続していることになります。この場合、データ・ソースのキューのサ
イズは、Web コンテナーのキューのサイズよりはるかに小さくて済みます。
•
逆に、処理のほとんどがデータベースに接続した状態で行われるサーブレットでは、Web コンテナ
ーのキューのサイズと、データ・ソースのキューのサイズはほとんど同じとなります。
トランスポート・チャネル
WAS V8.5 でも V6 から導入されたチャネルフレームワークが採用されています。
WAS V5.x では、図 10-5 WAS V5 における Web サーバー－HTTP トランスポート間の接続にあるよ
うに Web サーバー経由のリクエストはデフォルトで KeepAlive 接続となるため、一度 Web サーバーのプ
ラグインが WAS の HTTP トランスポートに対して生成した接続は切断されることなく次回のアクセスの際
に再利用されました。これによって、接続の生成・切断にかかる時間と負荷を軽減することができました
が、一方ではクライアントと Web コンテナーのスレッドが直接結びつくことで、特定のクライアントに Web
コンテナーのスレッドが占有されるという状態がありました。
図 10-5 WAS V5 における Web サーバー－HTTP トランスポート間の接続
WAS V6 以降では、図 10-6 にあるように TCP トランスポート・チャネルがクライアントからのリクエストを
受け付け、Web コンテナーのスレッドで使用可能状態であるスレッドにリクエストを割り当てていきます。
Web サーバーと Web コンテナー間が直接 KeepAlive 接続にならず間に TCP トランスポート・チャネルを
介することで、特定のクライアントが Web コンテナーのスレッドを占有するということがなくなりました。
Web コンテナーのスレッドは１クライアントのレスポンスを返した時点で、キューに入っているリクエスト
の処理を実行することができ、より有効にスレッドが使用されます。
図 10-6 WAS V6.0 以降の Web サーバー－トランスポート・チャネル間の接続
負荷分散時のキューイング・ネットワーク
負荷分散装置を使用して、リクエストを複数のサーバーに分散して実行する場合は、以下の点に注
意が必要です。
•
セッション・アフィニティなどの使用により、複数のサーバーに必ずしも均等に要求が振り分けられ
るとは限りません。偏る可能性がある場合は、各サーバーで同時に受け付ける要求数を多めに設
定することが必要な可能性もあります。
•
いったん分散された要求が合流するような箇所がある場合（DB サーバーが 1 台の場合など）はそ
の部分がボトルネックにならないよう、サーバーのサイジングやパラメーターの設定に十分に注意し
ます。
図 10-7 負荷分散時のキューイング・ネットワーク
10-2-1-2 WAS におけるパラメーター設定
システムを構成するキューのパラメーター、特にクローズド・キューにおける要求の最大同時実行数を
調整することは、システムのスループットを向上させるうえで重要です。これらには以下のパラメーターが
挙げられます。
Web サーバー
IBM HTTP Server（以下、IHS）の場合、パラメーターの設定は、<IHS_root>/conf/httpd.conf ファイル
で行います。IHS の最大同時実行数はファイル中の MaxClients/ThreadsPerChild ディレクティブで設定
します。設定値を超えた要求に対するタイムアウトは、Web ブラウザーごとの実装によって決定されま
す。IHS は v1.3 と v2.0 以降ではリクエストの処理方法が異なり、リクエストに対する親プロセス、子プロセ
スの振る舞いが異なります。10-2-2-1IBM HTTP Server のリクエスト処理方法(p.14)]を参照して下さい。
Web コンテナー
Web コンテナーの最大同時実行数は、アプリケーション・サーバーの Web コンテナー・スレッドのパラ
メーターで設定します。管理コンソールより、以下の手順で設定画面を表示します。
①
[ サ ー バ ー ] → [ サ ー バ ー ・ タ イ プ ] →[WebSphere Application Server] →
[ApplicationServer_name] → [コンテナー設定] → [Web コンテナー設定] → [Web コンテナー]
を選択し、対象のアプリケーション・サーバーの、Web コンテナーの設定画面を表示します。
②
Web コンテナーの設定画面から、[追加プロパティー]→[Web コンテナー・トランスポート・チェー
ン]→[WCInboundDefault]→[TCP インバウンド・チャネル(TCP 2)]→[関連項目]→[スレッド・プ
ール]→[WebContainer]と選択して、スレッド・プールの設定画面を表示します。
図 10-8 Web コンテナー・スレッド・プール
プール内のスレッドは、[最大サイズ]で設定した値まで、作成可能です。プール内で使用されていな
いスレッドは、[スレッド非活動タイムアウト]経過後に[最小サイズ]に設定したスレッド数まで破棄されま
す。
パラメーターの変更後は[適用]または[OK]ボタンを押下して、保管作業を行いアプリケーション・サーバ
ーの再始動が必要となります。
TCP トランスポート・チャネル
TCP トランスポート・チャネルで受け付ける接続の最大値は TCP インバウンド・チャネルで設定しま
す。管理コンソールより以下の手順で設定画面を表示します。
①
[ サ ー バ ー ] → [ サ ー バ ー ・ タ イ プ ] →[WebSphere Application Server] →
[ApplicationServer_name] → [コンテナー設定] → [Web コンテナー設定] → [Web コンテナー・ト
ランスポート・チェーン] を選択し、対象のアプリケーション・サーバーの、トランスポート・チェーン
の設定画面を表示します。
②
トランスポート・チェーンの設定画面から、[WCInboundDefault] → [TCP インバウンド・チャネル
(TCP 2)] を選択し、TCP インバウンド・チャネルの設定画面を表示します。
図 10-9 TCP トランスポート・チャネル
[最大のオープン接続数]で設定した数だけの接続を受け付けます。[非活動タイムアウト]ではリクエス
トがない状態で KeepAlive 接続が切断されるまでのタイムアウト値を設定します。
EJB コンテナー
EJB に対するメソッド呼び出しは、図 10-4 パラメーター調整に示されるように、EJB クライアントが
EJB の稼動している EJB コンテナー上ではなく、リモート・クライアントからの場合に限って、キューを介し
て行われます。
別プロセス内で動作する EJB クライアントからの EJB 呼び出しは、RMI/IIOP プロトコルによって行わ
れ、EJB コンテナー側の ORB によって処理されます。ここでは、ORB スレッド・プールが EJB コンテナー
のキューとしての役割を果たします。
ただし、ORB スレッド・プールは要求到着時に空きスレッドがない場合は、新規のスレッドを作成して
要求を実行し、このスレッドの実行が終了するとスレッドを破棄します。同時に実行されるスレッドの数に
上限が無いため、EJB コンテナーのキューはオープン・キューとなります。
EJB コンテナーのスレッド・プール・サイズは、こういったキューおよびアプリケーションの特徴を踏まえて
決定する必要があります。
管理コンソールより、[サーバー] → [サーバー・タイプ] →[WebSphere Application Server] →
[ApplicationServer_name] → [コンテナー設定] → [コンテナー・サービス] → [ORB サービス] → [追加
プロパティー] → [スレッド・プール設定] → [スレッド・プール設定] を選択して、スレッド・プールの設定
画面を表示します。
図 10-10 ORB スレッド・プール
プール内のスレッドは、[最大サイズ]で設定した値まで、作成可能です。プール内で使用されていな
いスレッドは、[スレッド非活動タイムアウト]経過後に[最小サイズ]に設定したスレッド数まで破棄されま
す。
パラメーターの変更後は[適用]または[OK]ボタンを押下して、保管作業を行いアプリケーション・サー
バーの再始動が必要となります。
データ・ソース
データ・ソースの最大同時実行数は、各データ・ソースの接続プールのパラメーターで設定します。
管理コンソールより、[リソース] → [JDBC] → [JDBC プロバイダー] → [JDBCProvider_name] → [追加
プロパティー] → [データ・ソース] → [DataSource_name] → [追加プロパティー] → [接続プール・プロ
パティー]を選択して、接続プールの設定画面を表示します。
図 10-11 接続プール
最大同時実行数は、最大接続数で設定します。
10-2-2 Web サーバー
10-2-2-1 IBM HTTP Server のリクエスト処理方法
IBM HTTP Server（以下、IHS） Unix 環境 V2.0 以降 (V2.0 / 6.0 / 6.1 / 7.0 / 8.0 / 8.5) と、Windows
環境のリクエスト処理方法を説明します。(WAS V8.5 では、IHS V7.0 以降をサポートしています。)
•
IBM HTTP Server V2.0 以降での処理方法（UNIX 系）
IHS V2.0 以降ではリクエストを子プロセスで処理させるのではなく、各々の子プロセスがスレッドを生
成し、そのスレッドによってリクエストが処理されます。IHS で同時に処理できるリクエスト数は httpd.conf
ファイルで設定する MaxClients で決定されますが、指定された数はリクエストを実行するスレッドの最大
数を示しています。
子プロセスが生成する各スレッドがリクエストを実行することによって、V1.3 よりも少ない子プロセス数
で多くのリクエストを実行することができます。子プロセス数の減少によって、子プロセスの生成にかかる
負荷を抑制できることができます。
親プロセス
リクエスト毎に
スレッド生成・消去
子プロセス
スレッド
スレッド
スレッド
子プロセス
スレッド
スレッド
スレッド
図 10-12 IHS V2.0 以降のリクエスト処理（UNIX 系）
•
Windows 環境での IBM HTTP Server (全バージョン共通) の処理方法
Windows 環境では、生成された親プロセスによって、１つの子プロセスが生成されます。子プロセスが
スレッドを生成し、そのスレッドによってリクエストが処理されます。最大同時実行数は ThreadsPerChild
で決定され、指定された数は生成される最大スレッド数を示しています。
図 10-13 Windows 環境のリクエスト処理（Windows）
IHS V8.5 のスレッド生成に関するディレクティブは以下になります。( )内は AIX 環境でのデフォルト値に
なります。
•
MaxClients(600)：サービスを行うスレッド合計数の上限
•
ThreadsPerChild(25)：各子プロセスが生成できるスレッド数
•
ThreadLimit(25)：ThreadsPerChild に設定可能な上限値
•
MaxSpareThreads(75)：待機状態のスレッドの数の上限
•
MinSpareThreads(25)：待機状態のスレッド数の下限
•
StartServers(1)：サーバー起動時に作成される子プロセスの数
•
MaxRequestsPerChild(0)：１つの子プロセスが処理できるリクエストの最大数
•
ServerLimit(64)：親プロセスが生成可能な子プロセスの上限
10-2-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 秒間隔で更新
します。
図 10-14 Server status ページ
10-2-3 データベース接続
データ・ソースを使用してデータベースへの接続を行う際のパフォーマンス上の考慮点について説明
します。
10-2-3-1 接続プール・サイズ
データベースへの接続を作成する処理は、非常に負荷のかかる処理となるため、WAS では作成した
接続をプールして再利用するという仕組みになっています。プールすることができる接続の最大数はデ
ータ・ソースのパラメーターの最大接続数で設定します。
10-2-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 データ・ソ
ース・プロパティのページを表示します。[ステートメント・キャッシュ・サイズ]フィールドで、１コネクション
あたりのステートメント・キャッシュの数を指定します。
図 10-15 WebSphere Application Server データ・ソース・プロパティ
ステートメント・キャッシュ・サイズは、Tivoli Performance Viewer で廃棄されるステートメント・キャッシュ
をモニターして調整することができます。ステートメント・キャッシュ数が設定した値を超えると、キャッシュ
は廃棄されていきます。廃棄が確認された場合はその数だけステートメント・キャッシュ・サイズを増加さ
せるとよいでしょう。10-3-2-4 モニタリング・ポイントの 6). データ・ソース接続プール」を参照して下さい。
10-2-4 JVM
JVM とは、Java 仮想マシン(Java Virtual Machine : JVM)のことで、Java バイトコードをそのプラットフォ
ームのネイティブコードに変換して実行するソフトウェアです。Java 言語で開発されたソフトウェアは、配
布時にプラットフォームから独立した独自の形式（Java バイトコード）になっており、そのままでは実行す
ることができません。このため、そのプラットフォーム固有の形式（ネイティブコード）に変換するソフトウェ
アを用意して、変換しながら実行します。この変換と実行を行うのが JVM です。
10-2-4-1 JVM のチューニング
Java アプリケーションの実行環境である JVM が使用する仮想ストレージは一般にヒープと呼ばれてい
ます。WAS V8.5 の使用している 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 ポリシー別に分けてヒープ・サイズのチューニング方法を解説していきま
す。
なお、WAS V8.5 より追加されたオンデマンド・ルーター（ODR）は、他のアプリケーション・サーバーと
同様に JVM プロセスとしてのチューニングを実施します。詳細は、「Proxy 章」の「ODR のチューニング」
節を参照してください。
10-2-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対象
図 10-16 「生きている」オブジェクトとガーベッジ
ヒープ･アロケーションおよびガーベッジ･コレクションのアルゴリズムについてはこれまで沢山の研究
が行われてきており、多種多様な手法がこれまで生み出されています。WAS V8.5 で使用されている J9
VM では以下にあげる 4 つの GC ポリシーが利用可能となっています。下記表には GC ポリシーの選択
の目安も記載していますが、あくまでも目安ですので実際にはパフォーマンス・テストを実施し最適な
GC ポリシーを決定します。WAS V7.0 までは Optimize for Throughput がデフォルトの GC ポリシーでし
たが、昨今、WAS のアプリケーション・サーバーに割り当てられる Java ヒープのサイズが大きくなる傾向
があり 、ま た一 時オ ブジェ クトを多用 するフ レーム ワ ークが増加し たこ と もあ り、 WAS V8 以降、
Generational Concurrent がデフォルトの GC ポリシーになりました。また、Balanced GC ポリシーが追加に
なっています。
表 10-1 GC ポリシーとその特徴
GC ポリシー
選択の目安
Optimize for Throughput
アプリケーションのスループットを重視する場合
Optimize for Pause Time
アプリケーションのレスポンスを重視し、GC による停止時間を抑える場合
Generational Concurrent
アプリケーションが生成するオブジェクトの生存期間が短い場合(デフォルト・
ポリシー)
Balanced
アプリケーションが多くのスレッドを使用し、動的なクラスのロード（リフレクシ
ョン）を多用している場合（64bit JVM で、4G 以上の Java ヒープ領域を割り
当てていることが前提）
※Subpooling
このポリシーは非推奨です。以前は固有のポリシーでしたが、現状では
Optimize for Throughput (optthruput) の別名となっています。
この 4 つの GC ポリシー共通で言えるのですが、どのポリシーでもヒープ内のオブジェクト管理方法と
して、ガーベッジがどこにあるのかを管理するのではなく、「生きている」オブジェクトがどこにあるのかを
管理しています。「生きている」オブジェクトが使用していない領域に存在しているオブジェクトをガーベ
ッジと判断して、その領域のメモリーを開放しています。
それでは具体的に個々の GC ポリシーについて見ていくことにします。
10-2-4-3 Optimize for Throughput (-Xgcpolicy:optthruput)
まずは Optimize for Throughput について解説します。以降表題とともに GC ポリシーを説明する際に
JVM に渡す引数を併せて記載します。
この GC ポリシーはガーベッジ･コレクションを Mark-Sweep-Compaction の三つのフェーズに分けて実
施します。Mark フェーズではヒープ内のすべての「生きている」オブジェクトにしるし(Mark)をつけます。
Sweep フ ェ ー ズ は 、 し る し の つ い て い な い オ ブ ジ ェ ク ト を 、 ヒ ー プ 内 か ら 掃 き と り (Sweep) ま す 。
Compaction フェーズはヒープ上に存在しているすべてのオブジェクトをヒープのアドレス領域の一端に
まとめる作業が行われます。Mark フェーズと Sweep フェーズはそれぞれそれほど大きな負荷とならない
ため毎回の GC で実施されます。それに対して Compaction フェーズはオブジェクトの移動が伴うため
個々のオブジェクトのコピーとメモリアドレス情報の再構成が行われます。そのため先の二つのフェーズ
と比べると負荷の大きな作業になるため、Compaction フェーズは発生条件が整ったときにのみ実施され
ます。例えば Mark&Sweep が行われた後にヒープ･アロケーションを行えるだけの十分な空き領域が
Free list にできなかった場合や、開放できた領域が少なくて全体の空き領域が一定以下だった場合で
す。System.gc()コールの場合を除いて、Compaction は必ず一度ガーベッジ･コレクションが実施された
後に行われます。
以下に各フェーズにおけるヒープ状況のイメージを示します。
ガーベッジ・コレクション実施直前：
Mark＆Sweepフェーズ実施後：
Compactionフェーズが実行された場合：
空き領域
図 10-17
割り当て済みの領域
Optimize for ThroughputGC ポリシーのガーベッジ・コレクション
以下に挙げる図は JVM のアプリケーション･スレッドの稼動状況を時間軸に沿って見てみた場合のイ
メージです。ガーベッジ･コレクション実行中はヒープへのアクセスを行っているすべてのスレッドが停止
するため、アプリケーションによるクライアントへのサービスもガーベッジ･コレクションが終了するまで停
止します。ちなみに、ヒープへのアクセスを行っていないスレッドと GC を実施しているスレッド(Allocation
Failure となったアプリケーション･スレッドがそのまま GC を実施します)はガーベッジ･コレクション中も稼
動できるようになっています。
スレッド1
スレッド2
スレッド3
…
スレッドn
時間
アプリケーション処理
ガーベッジ・コレクション(アプリケーション処理停止)
図 10-18 アプリケーション・スレッドとガーベッジ・コレクションの関係(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 領域と呼ばれ
ていました。
10-2-4-4 Optimize for Pause Time (-Xgcpolicy:optavgpause)
Optimize for Throughput では、JVM がガーベッジ・コレクションを実施している最中は、アプリケーショ
ン・スレッドの活動が止まっています。つまり、運悪くリクエストの到着がガーベッジ・コレクションの時間帯
にかぶってしまうと、ガーベッジ・コレクションによるリクエスト処理の停止の影響を受けるので、その分レ
スポンスが遅れます。ガーベッジ・コレクションが長くなるとその分最大レスポンス・タイムも大きくなる可
能性が出てくるわけです。アプリケーションやシステムのパフォーマンス要件によってはスループットより
もレスポンス・タイムのばらつきが小さいことがより優先されるケースもあります。そのような場合に検討対
象になる GC ポリシーがこの Optimize for Pause Time です。ヒープ管理のアルゴリズムは Optimize for
Throughput と同じ 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トレース
実施中は
アプリケーション処理停止
図 10-19 アプリケーション・スレッドとガーベッジ・コレクションの関係(Optimize for Pause Time)
10-2-4-5 Generational Concurrent (-Xgcpolicy:gencon)
WAS V8.0 からデフォルトとなった GC ポリシーがこの Generational Concurrent です。他の例と同様、
名称がこの GC ポリシーの性質をよく表しており、一般に「世代別 GC」と呼ばれる方法を採用していま
す。一言で Generational Concurrent の採用しているアルゴリズムの特徴を述べると、個々のオブジェクト
の想定される生存期間に応じて、ヒープ・アロケーションを行う場所を変えながらヒープ全体を管理する
というものです。具体的なヒープ管理方法を説明していきます。ヒープを Nursery 領域と Tenured 領域と
呼ばれる二つの異なる領域に分割します。新規に生成されるオブジェクトはまず Nursery 領域に割り当
てられます。オブジェクトがある回数のガーベッジ・コレクションをくぐり抜けて「生存」し続けることができ
ると、オブジェクトは Nursery 領域から Tenured 領域に移されます。生成されるほとんどのオブジェクトは
数回のオーダーの回数のガーベッジ・コレクションのうちに消滅する一方で、その期間中に生き残った
オブジェクトは比較的寿命が長いという一般則があります。そこで、「短命」のオブジェクトに対して集中
してガーベッジ・コレクションを行い、「長命」のオブジェクトはあるタイミングで別の領域に待避させる手
法をとることでガーベッジ・コレクションの効率を上げるというのがこの GC ポリシーのアルゴリズムです。
Nursery 領域はさらに二つの領域に分かれ、一方を Allocate 領域、もう一方を Survivor 領域と呼びま
す。ここで Generational Concurrent でのヒープモデルのイメージ図を以下に示します。
Nursery(New)領域
(Allocate領域)
Tenured(Old)領域
(Survivor領域)
図 10-20 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 コレクション
実施後：
空き領域
割り当て済みの領域
図 10-21 Scavengeｒコレクションの実行イメージ
ある程度 JVM が稼動し続けていると大抵は Tenured 領域もオブジェクトでいっぱいになります。その中
には閾値を超えたガーベッジ･コレクションを生き延びたものの、すでにガーベッジとなってしまっている
オブジェクトも存在します。そこで Tenured 領域に対してもガーベッジ・コレクションが実施されます。
Tenured 領域のガーベッジ・コレクションは Optimize for Pause Time と同じ方式がとられています。これに
より Tenured 領域のガーベッジ・コレクションにかかる時間を短縮します。GC ポリシー名に「Concurrent」
とついているのはこの Tenured 領域に採用されたガーベッジ・コレクションの性質を表しているためで
す。
なお、Scavenger 以外のコレクション、すなわち Mark-Sweep タイプのコレクションは Global コレクション
という名称がつけられており、Scavenger および Global の名称は verbose:gc ログの出力にも使用されて
います。
以下に Generational Concurrent 適用時のスレッドの稼動イメージを示します。Nursery 領域を対象とし
た Scavenger コレクションと、Tenured 領域を対象とした Concurrent トレースと Global コレクションが混在
します。
スレッド1
スレッド2
スレッド3
…
スレッドn
時間
アプリケーション処理
Scavengeコレクション
Globalコレクション
実施中は
アプリケーション処理停止
Concurrentトレース
図 10-22 アプリケーション・スレッドとガーベッジ・コレクションの関係(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 のロジック
の最適化を行っているため、パフォーマンス低下があまり起こらないようになっています。
10-2-4-6 Balanced (-Xgcpolicy:balanced)
WAS V8.0 からバランス GC ポリシーが新たに追加されました。この GC ポリシーでは、小さなサイズ（最
大 Java ヒープ・サイズで指定されたサイズの 1024 分の 1 の値を 2 の階乗に切り捨てたサイズ）の領域に
分割し、独立して管理することによって GC の割合を低減させます。各スレッドは、個別に空の領域を割
り当てられ、新規に作成されたオブジェクトに Allocate します。領域がいっぱいになると、その領域内で
Copying による GC を実行します。必要に応じて複数領域や全体の GC をおこないます。
図 10-23 BalancedGC ポリシーのイメージ
この方式は、割り当てた Java ヒープ・サイズが極めて大きく（4G 以上）、Nursery 領域に限定した GC
であっても停止時間が無視できなくなってきた場合に使用を検討します。H/W の特性やアプリケーショ
ンの条件によっては GC の時間を短縮することができる場合があります。
バランス GC ポリシーを使用するにあたって必須の条件が二つあります。一つは 64bit JVM を使用し
ていること、4G 以上の Java ヒープ領域を割り当てていることです。32bit 版の JVM や、4G 未満の Java
ヒープ領域しか割り当てていない場合にはバランス GC ポリシーは使用できません。
バランス GC ポリシーは、H/W が NUMA(Non-Uniform Memory Architecture)特性を持っており、多数
の CPU が並行して稼動している環境で特に効果が大きくなります。また、アプリケーションも多くのスレッ
ドを使用している場合に有利となります。また、アプリケーションがリフレクションを多用している場合にも
効果が期待できます。リフレクションを多用すると、メソッドやフィールドにアクセスするためのアクセッサ
クラスが一時オブジェクトとして多数作成されます。通常の世代別 GC では、Scavenger Collection ではク
ラス・オブジェクトが GC の対象とならないため、これらのクラス・オブジェクトが蓄積して Full GC をひきお
こすことがあります。バランス GC ポリシーでは、クラス・オブジェクトも通常の GC の対象となります。
一方、バランス GC ポリシーを使用すべきでない状況もいくつかあります。この GC ポリシーでは、空
き領域が十分にないと効率が悪くなるため、Java ヒープの使用率が恒常的に高い場合にはパフォーマ
ンスが悪化します。また、一つの領域に入りきらない大きなサイズのオブジェクトがある場合にも効率が
悪くなります。
8G や 12G などの巨大ヒープを割り当てたアプリケーション・サーバーなどの事例も出てきており、長
大な GC 時間を短くするというチューニングが実施したい場合には、この GC ポリシーの使用も検討して
下さい。
10-2-4-7 Java ヒープ・サイズのチューニング
ヒープ・サイズを適切に設定しておくことは JVM が適切なパフォーマンスを発揮する上で非常に重要
です。設定したヒープ・サイズが実際の必要量よりも少ないと Allocation Failure が相対的に多く発生しま
すのでガーベッジ・コレクションの実施頻度が上がりますし、最悪の場合メモリー不足エラー
(OutOfMemoryError)が発生してプロセスの稼動そのものができなくなる可能性も出てきます。また逆に
大きすぎるヒープ・サイズを設定すると、ガーベッジ･コレクションの実施時間が長くなります。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 の和を最小ヒープ・サイズに設定すると、初期化時に不要なヒープ拡張が発生することを回
避でき、起動パフォーマンスを向上させることができます。初期（最小）ヒープ・サイズ設定値を決定する
際は、verbose:gc ログ（後述）を有効にしたうえで WAS の起動直後にどのくらいヒープが必要になってい
るのかを確認することでおおよその値を決定することができます。
Application Footprint
2
• 稼動環境(アクセス数など)に依存（変動）
• オブジェクト(ex. 結果セットなどの一時利用変数)
• アプリのコア部分(固定)
• アプリケーションクラス
• 前提リソース
(ex. フレームワーク)
など
Application Footprint
1
• WASのコア部分(固定)
• WASランタイム
図 10-24
• ユーザー設定に依存（変動）
• 各種スレッドプール
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 Footprint 2 の部
分はテストフェーズにて実際に負荷をかけ、実際に最大数をロードしたタイミングでの verbose:gc ログか
ら必要なサイズの見積もりを行ないます。
Application Footprint 2 に分類されるオブジェクトの総サイズは稼動中のタイミングと条件によって大き
く変わってきます。HTTP セッション・オブジェクトを例にとると、セッションを有効にしている状況では
WAS に入ってくるリクエストの数に比例してオブジェクトが生成されますし、各オブジェクトのサイズもユ
ーザーの画面遷移やアクションによって変わってきます。そのためこの部分の見積もりについては、事
前にアプリケーション・サーバーの 1 プロセスあたりどのくらいのリクエスト受付を受容するかなどを決定し
た上で負荷テストを行ない、適切なサイズを決定するのが望ましいと言えます。
Generational Concurrent 以外の GC ポリシー適用時のチューニング
Generational Concurrent を GC ポリシーとして設定してない場合、ヒープは Mark&Sweep 方式による
Global コレクションが実施される領域と言い換えることができ、ヒープは JVM 内にひとつの領域として存
在ます。設定できる箇所は初期ヒープ・サイズ(これが最小値となります)と最大ヒープ・サイズとなり、それ
ぞれ-Xms,-Xmx の引数を JVM 初期化時に渡すことで設定できます。
設定例
システムの稼動状態にあわせて、ヒープ・サイズを JVM に動的に変更させることを許可する場合、最大
ヒープ・サイズを初期ヒープ・サイズよりも大きく設定します。また、ヒープ・サイズを固定する場合は初期
ヒープ・サイズと最大ヒープ・サイズの大きさを同じにします。
以下にいくつか具体例を示します。なお、WAS におけるヒープ・サイズの設定は例のように汎用 JVM
引数に設定を記述してもよいですし、管理コンソールの該当するサイズ入力欄に記入してもどちらでも
かまいません。
-Xgcpolicy:optthruput –Xmx768m
このケースでは GC ポリシーとして Optimize for Throughput を採用し、最大ヒープ・サイズを 768MB に
指定しています。初期ヒープ・サイズは明示的な指定が行われていませんので、JVM 初期化時には、デ
フォルトの初期ヒープ・サイズが確保されます。デフォルトの初期ヒープ・サイズは稼動プラットフォームに
よって異なり、例えば分散系の 32bit 環境では 50MB となります。初期化プロセスやリクエスト処理等によ
って初期ヒープ・サイズでは足りなくなると、JVM は 768MB を上限として適宜ヒープの拡張を行います。
大抵の場合、WAS を起動するのに初期ヒープ・サイズでは足りませんので、ヒープ拡張が入ることでサ
ーバー起動時間が長くなる可能性がありますので、WAS の起動時に必要とするヒープ・サイズを初期ヒ
ープ・サイズとして設定しておくとよいでしょう。
-Xgcpolicy:optthruput –Xms768m –Xmx1024m
このケースでは Optimize for Throughput ポリシーを適用して、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 コレクション一回あたりの実施時間は長
くなります。
ヒープサイズ可変
-XmsAm –XmxBm
0
B
A
ヒープサイズ固定
-XmsBm –XmxBm
0
B
図 10-25 Generational Concurrent 以外のヒープ・サイズ設定
Nursery領域 + Tenured領域
-XmsAm –XmxBm
0
B
A
図 10-26 Generational Concurrent のヒープ・サイズ設定例：
全体の最小サイズ・最大サイズのみを指定するケース
0
図 10-27
Nursery領域
Tenured領域
-XmnAm
-XmoBm
A
0
Generational Concurrent のヒープ・サイズ設定例：
Nursery 領域と Tenured 領域のサイズを固定するケース
B
Nursery領域
Tenured領域
-XmosCm –XmoxDm
-XmnsAm –XmnxBm
0
図 10-28
A
B
0
C
Generational Concurrent のヒープ・サイズ設定例：
Nursery 領域および Tenured 領域ともに動的な変更を許可するケース
設定例
Generational Concurrent を採用した場合のヒープは、Nursery、Tenured の各領域、および二つを合わせ
た全体のヒープ領域の三つの設定ポイントがあります。このうち Nursery+Tenured 領域からなる全体のヒー
プ領域の設定には Global コレクションの領域を定めたときと同じ-Xms、-Xmx を使用します。Nursery 領域
の設定は別名である new 領域のアルファベットの最初の n をとって、サイズを固定とする場合は-Xmn、動
的に変更を許可する場合の初期値は-Xmns、最大値は-Xmnx で指定します。Tenured 領域も同様に別名
の old 領域の頭文字をとって、固定とする場合は-Xmo を、動的に変更を許可する場合は-Xmos、-Xmox
で指定します。
以下に設定例を出しますが、ポイントはそれぞれの領域で明示的に固定値、ないしは｛初期値、最大
値｝のペアを指定しないと、稼動中に JVM が動的にサイズを変更するということです。
-Xgcpolicy:gencon –Xms768m –Xmx1024m
このケースでは全体のヒープ・サイズの初期値、最大値のみを指定して、Nursery および Tenured 領域へ
の配分を JVM に動的に変更させる設定となります。Nursery および Tenured 領域の初期値、最大値は、
全体のヒープ・サイズの初期値、最大値のそれぞれ 25%および 75%となります。
-Xgcpolicy:gencon –Xmns64m -Xmnx256m -Xmx1024m
このケースでは 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 の入力は必ずしも必要ではありません。ただし、最大
どれくらいの割り当てを行えるかをわかりやすくしておくためにこのように明示しておいても問題はありませ
ん。
D
10-2-4-8 Java ヒープ・サイズの設定
WAS の Java ヒープ・サイズの設定は管理コンソールから可能です。[サーバー]→[サーバー・タイプ]
→[WebSphere Application Server]→[ApplicationServer_name]→[サーバー・インフラストラクチャー]
→[Java およびプロセス管理]→[プロセス定義]→[追加プロパティー]→[Java 仮想マシン] を選択し
て、Java 仮想マシンの設定ページを表示します。
図 10-29 Java 仮想マシン設定
[初期ヒープ・サイズ]フィールドでは、JVM が起動時に確保するメモリー領域のサイズ（-Xms）を指定しま
す。
[最大ヒープ・サイズ]フィールドでは JVM が確保できるメモリー領域の最大サイズ(-Xmx)を指定します。
[汎用 JVM 引数]フィールドでは JVM が起動時に読み込む引数を指定することができます。この欄に
-Xms, -Xmx 引数でヒープ・サイズを指定することもできます。Generational Concurrent ポリシー適用時
で、Nursery/Tenured 領域の設定を行なう場合は他に設定欄がありませんので、汎用 JVM 引数に設定し
ます。
10-2-4-9 V7.0 以降での JVM ランタイムの改良点
WAS V7.0 以降では、パフォーマンス面でいくつかの改良が加えられています。共有クラスキャッシ
ュ、参照の圧縮というパフォーマンス向上に有効な 2 つの機能について説明します。
パラメーターの変更後は[適用]または[OK]ボタンを押下して、保管作業を行います。この設定は次回
のアプリケーション・サーバー起動時より有効になります。
10-2-4-10 共有クラスキャッシュ
JVM のパフォーマンス向上の仕組みのひとつとして共有クラスキャッシュがあります。これは IBM SDK
for Java V5 で導入されたもので、複数の JVM 間で使用するクラスを共有する仕組みです。この機能を
用いることにより JVM の起動時間の短縮と使用メモリーのフットプリントを減少させることができます。共
有クラスキャッシュは IBM SDK for JavaV5 で導入されましたが、V6 でいくつかの改良がされています。
V5 では OS を再起動させるとキャッシュ情報はクリアされてしまいましたが、V6 ではファイルに書き出す
ことによって OS 再起動をまたいでキャッシュ情報を保持させることが可能になっています。これにより OS
再起動後の最初の JVM 起動時間の短縮を図ることができます。
図 10-30 共有クラスキャッシュ
10-2-4-11 共有クラスキャッシュの設定
共有クラスキャッシュの設定はデフォルトで有効になっていますが、無効化したいときは管理コンソー
ルから設定することができます。[サーバー]→[サーバー・タイプ]→[WebSphere Application Server]→
[ApplicationServer_name]→[サーバー・インフラストラクチャー]→[Java およびプロセス管理]→[プロセ
ス定義]→[追加プロパティー]→[Java 仮想マシン] を選択して、Java 仮想マシンの設定ページを表示
します。この画面の[汎用 JVM 引数]に“-Xshareclasses:none”を設定します。
図 10-31 共有クラスキャッシュの無効化
停止時にキャッシュ情報をファイルに書き出す機能もデフォルトで有効になっています。共有クラスキ
ャッシュの機能を有効化したまま、この機能を無効化することも可能です。この場合は[汎用 JVM 引数]
に“-Xshareclasses:nonpersistent”を設定します。また、ここに“-Xshareclasses:persistent”を設定するこ
とにより、明示的に有効化することもできます。
詳細については以下の資料を参照下さい。
IBM SDK, Java Technology Edition, Version 6 - ク ラ ス ・ デ ー タ 共 有 の コ マ ン ド 行 オ プ シ ョ ン
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/topic/com.ibm.java.doc.user.aix32.60/user/sharedc
lassesxoptions.html
IBM SDK, Java Technology Edition, Version 7 Release 1-クラス・データ共有のコマンド行オプション
http://pic.dhe.ibm.com/infocenter/java7sdk/v7r0/topic/com.ibm.java.aix.70.doc/user/sharedclassesxoption
s.html
10-2-4-12 参照の圧縮 (Compressed references)
V6.1 では 64bit 版は 32bit 版と比較してヒープ使用量が多く、比較すると 60％程度増加する傾向にあ
りました。これはオブジェクト参照のポインターサイズは 32bit 版が 4 バイトであるのに対して 64bit 版では
8 バイトであるのが大きな原因でした。
V7 以降でも 64bit 版のヒープ使用量は 32bit 版と比較すると、V6.1 の場合と同程度大きくなります
が、ヒープ使用量を縮小する機能として参照の圧縮(Compressed references)が導入されています。これ
は文字通り 64bit 版の 8 バイトの参照を 4 バイトに圧縮する機能でヒープ使用量の削減に効果がありま
す。
ただし、ヒープ・サイズが 29GB 以下(サイズはプラットフォーム依存)の場合に限られ、Solaris 64bit
JVM などサポートされないプラットフォームもあります。
10-2-4-13 参照の圧縮の有効化
参照の圧縮機能は WAS V7.0.0.3 以降の 64bit 版で、-Xmx が 25GB 以下の場合は自動的に有効と
なります。WAS V8 以降の 64bit 版ではデフォルトで有効になっています。
参照の圧縮の詳細については以下の資料を参照下さい。
Java Diagnostics Guide 6 - Compressed references
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.java.doc.diagnostics.60/
diag/understanding/mm_compressed_references.html
10-2-4-14 ランタイム・プロビジョニング
WAS ランタイムのパフォーマンスを向上させる機能として、V7.0 からランタイム・プロビジョニングという
機能が追加されました。V6.1 まではアプリケーション・サーバーが起動する際、Web コンテナーや EJB コ
ンテナーなど全ての WAS 内部コンポーネントを起動していました。V7.0 以降ではランタイム・プロビジョ
ニング機能を有効にすると、対象アプリケーション・サーバー上のアプリケーションや設定に応じて必要
な WAS コンポーネントのみを起動します。例として、アプリケーション・サーバー上にデプロイしている全
てのアプリケーションが Servlet、JSP のみで構成されている場合、EJB コンテナーや Web Service コンポ
ーネントなどは起動されません。これにより、平均して 10%程度アプリケーション・サーバーの起動時間
が短縮され、Heap 使用量も減少させることができます。このランタイム・プロビジョニングはデフォルト
OFF で、デプロイメント・マネージャーやノード・エージェント、管理エージェント、ジョブ・マネージャーと
いった全ての JVM で設定できます。
図 10-32 ランタイム・プロビジョニング
10-2-4-15 ランタイム・プロビジョニングの有効化
ランタイム・プロビジョニングは管理コンソールから有効化することができます。[サーバー]→[サーバ
ー・タイプ]→[WebSphere Application Server]→[ApplicationServer_name]画面にて [必要に応じてコ
ンポーネントを開始]をチェックします。
図 10-33 ランタイム・プロビジョニング有効化設定
パラメーターの変更後は[適用]または[OK]ボタンを押下して、保管作業を行います。この設定は次回
のアプリケーション・サーバー起動時より有効になります。
10-3 モニタリング・ツール
パフォーマンス・チューニングを実施するにあたり、システムのどの部分がボトルネックとなっていて、
チューニングが必要なのかを見極めなければなりません。この節ではチューニングを実施する前段階と
して行うモニタリングについて、主要なモニタリング・ポイントと使用するモニタリング・ツールの使用方法
を説明します。最後には、モニタリングの結果の解析について述べます。
10-3-1 Performance Monitoring Infrastructure
WAS ではパフォーマンス・データを取得するために PMI というフレームワークを使用します。ここでは
PMI とその設定方法について説明します。
10-3-1-1 概要
WAS ではアプリケーション・サーバーのパフォーマンス・データを取得するフレームワークとして PMI
（Performance Monitoring Infrastructure）を提供しています。WAS では各リソースの様々なパフォーマン
ス・データを MBean(Managed Bean)という特別な JavaBean に格納しており、PMI はこの MBean と通信し
て各コンポーネントの必要なパフォーマンス・データを取得します。パフォーマンス・データを格納してい
る MBean は複数あり、それぞれ固有のデータを持っています。MBean には Java EE の仕様に定義され
ている Java EE 管理対象オブジェクトの MBeans と WebSphere PMI Perf MBean があります。Java EE
MBeans は特定のコンポーネントに関するパフォーマンス・データを提供し、Perf MBean は WebSphere
PMI サービスへのゲートウェイとして機能し、すべてのコンポーネントに対するパフォーマンス・データに
アクセスします。
PMI
ノード
JVMヒープ使用率、JDBC接続プール数
Webコンテナースレッド使用率、セッショ
ン作成数、GC発生率・・・・・
プラグイン
Web
サーバー
MBean
MBean
MBean
MBean
MBean
MBean
MBean
MBean
アプリケーション・サーバー
図 10-34 PMI の概念図
MBean
DB
PMI を使用してパフォ-マンス・データを取得するモニターツールとして、Tivoli Performance Viewer
（以下、TPV）、パフォーマンス・サーブレット、JMX インターフェースがあります（PMI クライアント API は
非推奨となっています）。これらを使用して、PMI が取得したパフォーマンスの統計データを取得するこ
とができます。
Tivoli Performance Viewer は WAS の管理コンソールに組み込まれているパフォーマンス・モニター・ツ
ールです。パフォーマンス・サーブレットは、パフォーマンス・データを XML 形式で出力するサーブレッ
トでこちらも WAS で提供されています。また、JMX インターフェースはユーザー独自のモニター・アプリ
ケーションを開発する場合に使用します。
10-3-1-2 モニターできるデータ
パフォーマンス・データは、それぞれのコンポーネントに対応したモジュールというカテゴリーでグルー
プ化されています。モジュールには以下のものがあります。
－エンタープライズ Bean
－JDBC 接続プール
－JCA 接続プール
－JVM ランタイム
－オブジェクト・リクエスト・ブローカー（ORB）
－サーブレット・セッション・マネージャー
－トランザクション・マネージャー
－スレッド・プール
－Web アプリケーション
－ワークロード管理（WLM）
－システム・データ
－動的キャッシング
－Web サービス・ゲートウェイ（WSGW）
－Web サービス
－アラーム・マネージャー
－オブジェクト・プール
－スケジューラー
－高可用性マネージャー（HAManager）
－DCS 統計
－システム統合バス（SIB サービス)
－SipContainerModule
－ARD 要求
－xdProcessModule
10-3-1-3 PMI 設定
WAS V7.0 以降では PMI はデフォルトで使用可能になっています。管理コンソールより[モニターおよ
びチューニング]→[Performance Monitoring Infrastructure (PMI)]→[AppServer_name]を選択する
と、モニターできるパフォーマンス・データは統計のセットとして、表 10-2 に示す４つの定義済みの統計
セットが提供されています。定義済みの統計セットの他に[カスタム]のリンクをクリックして、モニターする
パフォーマンス・データを選択することが可能です。デフォルトで[基本]となっているため、より多くのパフ
ォーマンス・データをモニターするためには、[現在モニターされている統計セット]で[なし]、[基本]、[拡
張]、[すべて]、[カスタム]のいずれかにチェックを付けて、適切な統計セットを設定します。統計セットの
変更後はアプリケーション・サーバーを再始動する必要があります。
図 10-35 PMI 設定
表 10-2 統計セット
統計セット
なし
基本
拡張
すべて
カスタム
説明
すべての統計を使用不可にします。
ランタイムおよびアプリケーション・コンポーネントに関する基本的なパフォーマンス・デー
タを提供します。Java EE で指定された統計および CPU や HTTP セッションなどの基本的
な統計が使用可能になります。デフォルトの統計セットに設定されています。
ランタイムおよびアプリケーション・コンポーネントに関する詳細なパフォーマンス・データ
を提供します。WAS コンポーネントの基本セットおよびキー統計が使用可能になります。
すべての統計が使用可能になります。
統計を選択して、モジュールごとに使用可能または使用不可に設定します。
10-3-2 Tivoli Performance Viewer
Tivoli Performance Viewer（以下、TPV）は管理コンソールに組み込まれた WAS のパフォーマンス・モ
ニタリング・ツールです。TPV を使用することによって、管理コンソールから WAS の各リソースの状況を
モニターすることができます。
10-3-2-1 モニターの開始
WAS の現在のリソース状況のモニター方法を説明します。TPV ではノード上のすべてのアプリケーシ
ョン・サーバーとノード・エージェントがモニター対象となります。
①
管理コンソールより[モニターおよびチューニング]→[Performance Viewer]→[現行アクティビティ]
を選択するとアプリケーション・サーバーとノード・エージェントの一覧が表示されるので、モニター
の対象のアプリケーション・サーバー、またはノード・エージェントにチェックボックスにチェックを付
けて、[モニターの開始]ボタンを押します。[コレクション状況]が[使用可能]から[モニター対象]に
変更することで、モニター開始が確認できます。この時点からパフォーマンス・データの収集が開
始します。
図 10-36 モニターの開始
②
モニター対象のアプリケーション・サーバー、またはノード・エージェントのリンクをクリックすると
TPV コンソール・パネルが表示され、左側にナビゲーション・ツリー、右側に現行のパフォーマン
ス・アクティビティのリアルタイムのデータが表示されます。
10-3-2-2 ユーザー設定およびロギング設定
TPV のモニターでは以下のユーザー設定およびロギング設定が可能です。
ユーザー設定
ユーザー設定では収集するパフォーマンス・データに関する以下の値の設定を必要に応じて行いま
す。TPV コンソール・パネルのナビゲーション・ツリーより[設定]→[ユーザー]を選択し[ユーザー設定]ペ
ージを表示します。
リフレッシュ頻度
パフォーマンス・データを収集する間隔を秒単位で指定します。デフォルトでは３０秒です。指定可能な
数値は５秒から５００秒です。
バッファー・サイズ
収集したデータを一時的に保管する際のデータ量を指定します。TPV で表示されるデータは、ノード・
エージェントのヒープ内のバッファーに保管されるため、バッファーがフルになった後は、古いデータか
ら破棄されていきます。デフォルトのバッファー・サイズは４０です。指定可能な値は１０から１００です。バ
ッファー・サイズが大きいとそれだけ、ヒープを消費するので適切な設定をする必要があります。
データ表示
収集したデータの表示方法を設定します。以下の選択が可能です。
−
生データ：収集したデータの絶対値を表示します。
−
値の変化：直前の値と現行までの値の変化を表示します。
−
変化率：値の変化を時間で割った値を表示します。
図 10-37 ユーザー設定
ロギング設定
ロギング設定ではロギングに関する以下の設定を行います。
期間
[ロギング開始]をしてから[ロギング停止]を行わない限り、ロギングを継続する時間を設定します。デフォ
ルトでは２０分です。
最大ファイル・サイズ
ひとつのログ・ファイルのサイズを指定します。TPV ではログ・ファイルを自動で ZIP 形式に圧縮します
が、このパラメーターは圧縮前のファイル・サイズの指定となります。
ヒストリー・ファイルの最大数
ログ・ファイルは循環ログとなっているため、TPV が書き込むファイルの最大数を指定します。
ファイル名
ログ・ファイルのプレフィックスを指定します。実際のファイル名は以下のようになります。
<prefix>_<process_name>_<timestamp>_<suffix_number>.zip
ログ出力フォーマット
ログ・ファイルのフォーマットを XML もしくはバイナリーに指定します。バイナリーの方がログ・ファイルの
解凍後のファイル・サイズは小さくなります。
図 10-38 ロギング設定
10-3-2-3 現行アクティビティの表示（パフォーマンス・モジュール）
TPV コンソール・パネルのナビゲーション・ツリーの[パフォーマンス・モジュール]を展開すると、TPV
で取得できる WAS のモニター項目が表示されます。チェックボックスにチェックを付けたモニター項目
についてビューアーに表示されます。[モジュールの表示]ボタンを押すことで、ビューアーにグラフ表示
されます。（PMI は指定したレベルの全データを取得していますが、ビューアーに表示されるのはチェッ
クを付けたモニター項目のみです。）
図 10-39 現行アクティビティの表示
ビューアーにおけるデータ表示
•
グラフの表示
取得データを 図 10-39 のようにグラフ表示
•
表の表示
取得データを表形式で表示
•
バッファーのクリア
表、またはグラフ形式で現在ビューアーに表示されている値を削除します。データ取得の停止後
に実施すると、ビューアー上のデータが削除されます。
•
ゼロにリセット
取得されるデータには、取得開始からの相対値を表すデータと、取得時のリアルタイムでの値を表
すデータがあります。データが相対値である場合、この操作によってデータはゼロにリセットされ操
作時点を開始時刻としてデータの表示が再開されます。データがリアルタイムの状態を表すロー
ド・データである場合、リセットはできないので影響はありません。この操作を行うと、[バッファーの
クリア]での操作も同時に行われます。
•
名前
グラフのマーカーに対応する値については、ビューアー下に表形式で表示されます。[名前]にカ
ーソルを当てると値の説明を確認することができます。
•
尺度
グラフに表示する値の倍率を設定することができます。実際の値に[尺度]を乗じた値（「尺度の
値」）がグラフに表示されます。
10-3-2-4 モニタリング・ポイント
Web システムにおいてパフォーマンスを考慮する場合の主要なモニタリング・ポイントとして以下の図
に示す 10 項目がありますが、ほとんどの項目については Tivoli Performance Viewer を使用してモニタ
ーすることができます。これらの主要モニタリング・ポイントについて Tivoli Performance Viewer のどのパ
フォーマンス・モジュールでモニターしていくのかについて説明します。
図 10-40 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
基本
メモリー内にあるセッション数
NoRoomForNewSession
拡張
「オーバーフローの許可」がチェックされていない際に適用。新
規セッションの要求を処理できない合計回数。
Count
CacheDiscardCount
すべて
分散セッションでキャッシュから破棄されたセッションの合計数
ExternalReadTime
拡張
分散セッションで、外部からセッション・オブジェクトを読み取る
のにかかった時間（ミリ秒）
ExternalReadSize
拡張
分散セッションで、外部から読み取ったセッション・オブジェクト
のサイズ
ExternalWriteTime
拡張
分散セッションで、外部にセッション・オブジェクトを書き込むの
にかかった時間（ミリ秒）
ExternalWriteSize
拡張
分散セッションで、外部に書き込んだセッション・オブジェクトの
サイズ
AffinityBreakCount
すべて
フェイル・オーバーなどで中断されたアフィニティの合計数
TimeSinceLastActivated
すべて
セッション・オブジェクトに対してのアクセス間隔の平均時間（ミ
リ秒）
TimeoutInvalidationCou
すべて
タイムアウトにより無効になったセッションの数
すべて
タイムアウトが原因で存在していないセッションに対するリクエ
nt
ActivateNonExistSession
ストの合計数
Count
SessionObjectSize
すべて
メモリー内のシリアライズ化されたセッション・オブジェクトのサ
イズ
4).
Web サーバー・スレッド
Web サーバー・スレッドのモニタリングは、Tivoli Performance Viewer ではできません。「10-2-2-2
IBM HTTP Server のモニタリング」を参照して下さい。
5).
スレッド・プール
Web コ ン テ ナ ー ・ ス レ ッ ド ・ プ ー ル の 情 報 は パ フ ォ ー マ ン ス ・ モ ジ ュ ー ル [ ス レ ッ ド ・ プ ー
ル]→[WebContainer]でモニターすることができます。
ORB スレッド・プールの情報はパフォーマンス・モジュール[スレッド・プール]→[オブジェクト・リクエ
スト・ブローカー]でモニターすることができます。
各スレッド・プールについて取得可能なデータは同じになります。以下の表に、[スレッド・プール]
でモニターできるスレッド・プールのデータを示します。
名前
統計セット
説明
CreateCount
すべて
作成されたスレッドの合計数
DestroyCount
すべて
破棄されたスレッドの合計数
ActiveCount
拡張
同時にアクティブなスレッドの数とその平均値
PoolSize
基本
プール内のスレッドの数とその平均値
PercentMaxed
すべて
プール内のすべてのスレッドが使用中である時間の平均比率
（％）
DeclaredThreadHungCo
すべて
ハング宣言されたスレッドの総数
すべて
クリアされたハングスレッド数
unt
ClearedThreadHungCou
nt
ConcurrentHungThreadC
すべて
同時に停止したスレッド数
すべて
スレッドがアクティブな状態である平均時間（ミリ秒）
ount
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
基本
接続が割り振られるまでの平均待ち時間（ミリ秒）
ManagedConnectionCou
すべて
プール内の接続数（物理接続数）
ConnectionHandleCount
すべて
getConnection()によって割り振られた接続ハンドルの数
PrepStmtCacheDiscardC
拡張
廃棄された PreparedStatement の合計数
拡張
JDBC ドライバー内での実行にかかった時間（ミリ秒）
nt
ount
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 は使用可能になります。
10-3-2-5 ロギング
Tivoli Performance Viewer（以下、TPV）のロギング処理では、取得データをログ・ファイルに出力して
残し、一定期間のリソース状況を再生することが可能です。
ログの取得
ログの取得方法を説明します。左側ツリーの上部に[モジュールの表示]ボタンを押して、ビューアーを表
示します。ビューアー上部の[ロギング開始]ボタンを押すとログの出力が開始します。ロギングを停止し
たいタイミングで[ロギング停止]ボタン押してログ出力を停止します。
図 10-41 ロギング設定
ログ・ファイルの設定については「10-3-2-2 ユーザー設定およびロギング設定」のロギング設定を参照し
て下さい。
ログの再生
ロギング処理で取得したログ・ファイルをビューアーで再生する手順を説明します。
①
管理コンソールのナビゲーション・ツリーから[モニ ターおよびチューニング]→[Performance
Viewer]→[ログの表示]を選択して、ログ・ファイルの選択画面を表示します。
②
[ログ・ファイルの明示的パス]にチェックをいれて、参照ボタンでログ・ファイルを選択します。ログ・
ファイルは記録中には.xml（XML フォーマット）もしくは.tpv（バイナリーフォーマット）を拡張子に持
つファイルに出力されますが、記録停止後に自動的にファイルサイズ縮小のために ZIP 形式のファ
イルに圧縮されます。
③
[ログの表示]ボタンを押すと、ビューアーが表示され、ログの再生が開始します。
図 10-42 ログ・ファイルの選択
④
TPV のツリーのパフォーマンス・モジュールからモニターするモジュールにチェックを付けて、[モジ
ュールの表示]ボタンを押すと、ビューアーにデータが表示されます。
⑤
ビューアー上部のボタンでログ・ビューの調整が可能です。ログの表示が終了するまで、ログの再
生が行われます。
巻き戻し：ログ・ファイルの最初に戻ります。
停止：現在の場所でログを停止します。
再生：現在の場所からのログを再生します。
高速前進：次のデータ・ポイントを 3 秒ごとにロードします。
高速前進 2：10 のデータ・ポイントを 3 秒ごとにロードします。
図 10-43 ログの再生
10-3-3 パフォーマンス・アドバイザー
パフォーマンス・アドバイザーは WAS でパフォーマンス・チューニングのアドバイスを通知するツール
です。パフォーマンス・アドバイザーには、Runtime Performance Advisor と Tivoli Performance Viewer で
提供される Performance Advisor（TPV Advisor）があります。共に PMI で取得したデータを元に、スレッ
ド・プール、接続プール、Prepared Statement Cache、セッション、ヒープ・サイズなどのチューニングを示
唆します。設定については 10-3-1-3PMI 設定(p.41)」を参照して下さい。
パフォーマンスおよび診断アドバイザー
パフォーマンスおよび診断アドバイザーはアプリケーション・サーバー上で稼動し、パフォーマンスを
定期的にチェックしてパフォーマンス・チューニングに関するアドバイスを管理コンソールの[WebSphere
ランタイム・メッセージ]と標準出力である SystemOut.log ファイルに出力します。パフォーマンスおよび診
断アドバイザーを使用することによるシステムへの負荷はほとんどありません。
パフォーマンスおよび診断アドバイザーはデフォルトでは使用可能になっていません。管理コンソー
ルから[サーバー]→[アプリケーション・サーバー]→[ApplicationServer_name]→[パフォーマンス]→[パ
フォーマンスおよび診断アドバイザー構成]を選択してパフォーマンスおよび診断アドバイザー構成ペ
ージを表示します。構成タブの一般プロパティーで[パフォーマンスおよび診断アドバイザー・フレーム
ワーク (ランタイム・パフォーマンス・アドバイザー) を使用可能にする]のチェックボックスにチェックを付
け、[適用]または[OK]ボタンを押下し保管処理を行います。アプリケーション・サーバーを再始動するこ
とでパフォーマンスおよび診断アドバイザーは使用可能になります。ランタイムタブで設定を行った場合
は、アプリケーション・サーバーの再始動は必要ありません。
図 10-44 パフォーマンスおよび診断アドバイザー
以下のリソースに対してのアドバイスを通知します。

ORB サービス・スレッド・プール

Web コンテナー・スレッド・プール

接続プール・サイズ

Persisted セッション・サイズおよび時間

Prepared Statement キャッシュ・サイズ

セッション・キャッシュ・サイズ

メモリー・リークの検出
TPV Advisor
TPV Advisor は TPV 上で使用されるもので、管理コンソールでリソースの状況やアドバイスを表示しま
す。TPV コンソール・パネルのナビゲーション・ツリーの[アドバイザー]を選択して TPV Advisor を表示し
ます。更新間隔は TPV と同様に指定することが可能です。設定方法については、10-3-2-2 ユーザー設
定およびロギング設定(p. 42 )」を参照して下さい。
図 10-45 TPV アドバイザー
パネル上部の表では Web コンテナーと EJB コンテナーにおける要求数/秒と応答時間(ミリ秒)を表示し
ます。円グラフでは CPU の使用時間とアイドル時間のパーセンテージを表示しています。
パネル中部の表では、各スレッド・プール、接続プールの使用状況を表示します。
以下のリソースに対してのアドバイスを通知します。

ORB サービス・スレッド・プール

Web コンテナー・スレッド・プール

接続プール・サイズ

Persisted セッション・サイズおよび時間

Prepared Statement キャッシュ・サイズ

セッション・キャッシュ・サイズ

動的キャッシュ・サイズ

JVM ヒープ・サイズ

DB2 Performance Configuration Wizard
10-3-4 要求メトリック
Performance Monitoring Infrastructure(PMI)要求メトリックは、Web コンテナー、ＥＪＢコンテナー、デー
タベースなどの主要コンポーネントにおいて経過した時間を計測し、ログに記録する機能です。リクエス
トが WAS 内でコンポーネント間の移動にかかった時間を測定することができるので、実行環境とアプリケ
ーションのパフォーマンス問題を識別するのに役立ちます。
実稼動環境での稼動を考慮し、IP アドレスまたは URI、EJB メソッド、JMS パラメーター、Web サービ
ス・パラメーターによりフィルター操作することができます。フィルタリングすることでパフォーマンスの劣
化を防ぐことができます。
計測対象コンポーネント
以下の中から選択したコンポーネントを対象として、リクエストが入ってから出るまでの経過時間を計測
し、ログに出力します。
−
Web サーバー・プラグイン
−
プロキシー・サーバー
−
Web コンテナー
−
EJB コンテナー
−
データベース
−
JCA（J2EE コネクター・アーキテクチャー）
−
Web サービス
−
JMS
−
サービス統合バス
−
ポートレット・コンテナー
−
非同期 Bean
図 10-46 要求メトリックのログ
10-3-4-1 基本使用方法
要求メトリックの基本的な使用方法についての手順を説明します。
①
管理コンソールのナビゲーション・ツリーから[モニターおよびチューニング]→[要求メトリック]を選
択して要求メトリックの設定画面を表示します。デフォルトでは要求メトリックは使用可能になってい
ます。要求メトリックを使用しない場合は、[要求メトリック・コレクション用のサーバーの準備]のチェ
ックを外します。
②
計測対象とするコンポーネントを[計測対象コンポーネント]から選択します。[カスタム]を選択すると
複数の任意のコンポーネントを選択可能です。
③
[要求メトリックの宛先]の[標準ログ]にチェックを付けて、要求メトリックで取得するデータのログ・フ
ァイルへの出力をＯＮにします。この設定を行わないとログへ出力されませんので注意が必要で
す。ログは SystemOut.log に出力されます。
④
設定を終えたら、[OK]ボタンを押して、構成の保管を行います。
⑤
要求メトリックで Web サーバー・プラグインを計測対象とする際には、Web サーバー・プラグインの
構成ファイルに設定が反映されます。したがって、管理コンソールから「プラグインの生成」を行う必
要があります。
図 10-47 要求メトリック設定
10-3-4-2 トレース・レベルの設定
トレース・レベルの設定では、要求メトリックで取得するデータの詳細レベルを設定します。以下のレ
ベルから選択します。（[なし]よりも高いレベルを設定します。）
•
なし：トレースを取得しません。
•
ホップ：プロセス境界のみの計測情報を取得します。
•
パフォーマンス・デバッグ：ひとつの追加レベルの計測データを取得します。
•
デバッグ：すべてのプロセス内のサーブレットおよび EJB 呼び出しの応答時間を含む、詳細な計測
データを提供します。
10-3-4-3 フィルターの設定
要求メトリックのオプション機能としてフィルターを使用することによって、特定の箇所のみのトレースを
取得することが可能です。要求メトリックを使用すると、ログ・ファイルに大量のデータを出力するために
パフォーマンスの劣化を招きかねません。フィルターを使用して、取得するデータを限定することによっ
て、パフォーマンスの劣化を防ぐことができます。
HTTP リクエストに対するフィルター
WAS が受ける HTTP リクエストに対して、「送信元 IP アドレス・フィルター」と「URI フィルター」を使用し
てフィルタリングが可能です。
•
送信元 IP アドレス・フィルター
HTTP リクエストの送信元の IP アドレスに基づいてフィルターを掛けます。
•
URI フィルター
HTTP リクエストの URI に基づいてフィルターを掛けます。
送信元 IP アドレス・フィルターと URI フィルターを両方とも設定した場合、要求メトリックでは、両方のフィ
ルター・タイプに一致する必要があります。
EJB リクエストに対するフィルター
EJB リクエストに対して、「EJB メソッド名フィルター」を使用して、フィルタリングが可能です。
•
EJB メソッド名フィルター
EJB メソッドの絶対パス名に基づいてフィルターを掛けます。
JMS フィルター
JMS リクエストに対して、キュー宛先名およびトピック宛先名に基づいてフィルターを掛けます。
例：destination=aaa:topic=bbb
Web サービス・フィルター
Web サービスのリクエストに対して、WSDL のポート名、オペレーション名、トランスポート名の組み合わ
せに基づいてフィルターを掛けます。
例：wsdlPort=aaa:op=bbb:namespace=ccc
10-3-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
JMS 送受信
非同期 Bean
Web サービス
JCA
JNDI
SIB
SIB 送受信
す時に使用される URI が記録されます。
Enterprise Bean の完全修飾パッケージおよびメソッド名です。
作成済みステートメントの select,update,insert,delete 値。作成されていないステートメント
の場合は、完全なステートメントが表示されることがあります。
JMS パラメーターの詳細が含まれます。
JMS のメッセージの送受信により、トレース・レコードを生成します。
非 同 期 Bean の 名 前 を 指 定 す る 詳 細 。 非 同 期 ビ ー ン に は 2 つ の タ イ プ 、
COMMONJ_WORK_POOLED および COMMONJ_TIMER が含まれています。
Web サービス・パラメーターの詳細が含まれています。
J2EE コネクター・アーキテクチャー。 JCA 呼び出しが行われたクラス名が表示されま
す。
JNDI ネーミング検索に使用されます。 JNDI 名が表示されます。
メッセージの送受信およびメディエーションを含むサービス統合バス内での計測に使
用されます
SIB のメッセージの送受信により、トレース・レコードを生成します。
10-3-5 verbose:gc
verbose:gc ログは JVM によるガーベッジ・コレクションが実施された際の詳細な実施結果を取得するこ
とのできるログです。例えば、コレクションの実施頻度や各コレクションの所要時間、開放されたヒープ領
域の大きさなどがわかりますので、問題判別時のガーベッジ・コレクションの挙動調査にも使われます。
10-3-5-1 verbose:gc の設定方法
verbose:gc を有効にするには JVM に-verbose:gc オプションを設定します。管理コンソールから設定が
可能です。管理コンソールのナビゲーション・ツリーより[サーバー]→[サーバー・タイプ]→[WebSphere
Application Server]→[ApplicationServer_name]→[サーバー・インフラストラクチャー]→[Java および
プロセス管理]→[プロセス定義]→[追加プロパティー]→[Java 仮想マシン] を選択し、Java 仮想マシン
の設定ページを表示します。このページに冗長ガーベッジ・コレクションのチェックボックスがあります。こ
こにチェックを付けると次回アプリケーション･サーバーが始動するタイミングから verbose:gc ログが出力
されるようになります。デフォルトの出力先は<WAS_root>/profiles/<profile_name>/logs/native_stderr.log
です。
verbose:gc ログは JVM 汎用引数[-verbose:gc]を入れることでも取得が可能です。設定後はアプリケー
ション・サーバーの再起動が必要になります。
また、-Xverbosegclog オプションを指定することによって出力先ファイルを明示的に指定することも可能
です。
図 10-48 Java 仮想マシン設定
10-3-5-2 verbose:gc の出力内容
10-3-4-7「Java ヒープ・サイズのチューニング」の項目で説明したように、ガーベッジ･コレクションには
領域の観点から整理すると Scavenger と Global の二つのタイプがあります。Generational Concurrent 以
外の GC ポリシーでは Global コレクションにて実施されます。さらに実施タイミングの観点から Global 領
域におけるコレクションには Optimize for Pause Time、また Generational Concurrent のアルゴリズムを適
用 し た 際 に は Concurrent コ レ ク シ ョ ン が 実 施 さ れ ま す 。 Concurrent コ レ ク シ ョ ン は Generational
Concurrent 適用時の Tenured 領域でも実施されます。整理すると下図のようにまとめることができます。
表 10-49 各 GC ポリシーで実施されるコレクション形態
GC ポリシー
コレクション方法
Optimize for Throughput
Global
Optimize for Pause Time
Concurrent および Global
Generational Concurrent
Scavenger ( Nursery 領域)
Concurrent および Global (Tenured 領域)
Balanced
Scavenger および Global
ここでは Concurrent コレクションを含めた 3 種類のコレクションが実施された際の出力内容について見て
いくことにします。
Global コレクション
まずは Optimize for Throughput の出力例を見ていくことにします。
<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>
図 10-50 verbose:gc ログ出力例（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 コレクション適用時の verbose:gc ログの出力内容と
比較すると 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>
図 10-51 verbose:gc ログ出力例（Scavenger コレクション）
Global コレクションの出力と同様に、ガーベッジ・コレクションの開始はトリガーとなる Allocation Failure
の発生を示す<af>タグにより始まります。違いは type 属性が Scavenger コレクションの実施場所を示す
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 領域に分かれて
表示されている他は Global コレクションと同じです。出力されている Nursery 領域の大きさは実際には
Allocation 領域の大きさを示しています。そのため、実際に確保されている Nursery 領域に Tilt Ratio を
掛け合わせた値が表示されます。このときに適用されている Tilt Ratio はひとつ前のガーベッジ･コレクシ
ョンにて決定されたものです。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>タグの出力から取得することができます。またこのガーベッジ・コレクションの実施結果
に従って算出された Tilt Ratio の値が出力されます（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>
図 10-52 verbose:gc ログ出力例（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 処理の実施結果が出力され
ます。mutators 属性の値はアプリケーション(ミューテーターと呼ばれます)がトレースした結果、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 コレクションの一部に組み入れるかのいずれかの動きをとります。どちらの行動を選択したかは
verbose:gc ログの中の<con >タグで”aborted”となっているか”halted”となっているかで判断できます。
10-3-6 Intelligent Management 機能によるモニタリング
WAS V8.5 より追加になった Intelligent Management 機能でも、モニタリングするツールを提供してい
ます。ここでは、リアルタイムにシステム状況を見るための、レポート機能、オペレーション・アラート、ラン
タイム・タスクと、長期の統計情報に利用できる、可視化データ・サービスについて紹介します。
10-3-6-1 レポート機能
レポート機能は、パフォーマンス状況をリアルタイムに図表で視覚化するツールです。管理コンソール
のナビゲーション・ツリーより[ランタイム操作]→[レポート]→[データの追加]で、取得したいデータを指
定します。
 データ・セット・タイプ
 取得データの項目名（サービス・ポリシーや動的クラスターなど）
 データ・セット
 サービス・ポリシーなど実際に設定されている名前
 使用可能なメトリック
 上記で選択したデータ・セットで取得できる統計情報
 「平均応答時間」、「平均スループット」、ノードの「CPU 使用率」、「合計メモリー」など
図 10-53 レポート機能の設定
上記で設定したデータは、管理コンソールのナビゲーション・ツリーより[ランタイム操作]→[レポー
ト]で、サービス・ポリシーごとの平均応答時間やノードごとの CPU 使用率など様々な情報をリアルタイ
ム見ることができます。
図 10-54 レポートの表示
レポート機能の詳細は、「6 章システム管理」の「レポート」節を参照してください。
10-3-6-2 オペレーション・アラート
オペレーション・アラートは、発生している問題を通知し、必要に応じてアクションを実行できるようにア
ドバイスをしてくれる機能です。状況を通知する場合と、アクションプランを一緒に提示するケースがあり
ます。オペレーション・アラートは、管理コンソール上の[ランタイム操作]以下の各メニューや、動的クラス
ターの[オペレーション]タブなどで参照可能です。システムの管理者は管理コンソールに表示されるこ
のオペレーション・アラートに注意することで、現在の稼働環境で起きている可能性がある問題を早期に
発見し、対応をとることが可能となります。
図 10-55 オペレーション・アラート
10-3-6-3 ランタイム・タスク
WAS V8.5 環境では、ラインタイム・コンポーネントによってさまざまなタスクが生成されます。主には、
オートノミック・マネージャーが検知するポリシー違反などが含まれます。オートノミック・マネージャーに
よって検知されたポリシー違反は、タスクとして生成され、デプロイメント・マネージャーに送信されます。
生成されたタスクは管理コンソールのランタイム・タスクから確認できます。タスクは一覧表示され、個々
のタスクの詳細画面へのリンクを含みます。
また、監視モードに設定されている場合は、アクションは管理者がタスクを受諾するまで実行されませ
ん。管理者はタスクの中身を確認し、アクションの実行を承認する場合は受諾を選択し、サブミットを実
行します。
タスク管理では、さらに通知機能を設定することでランタイム・タスクにタスクがあがったことをトリガー
に、指定したログに書き出したり、指定したアドレスに e-mail を送信したりすることも可能です。監視モー
ドの際に通知機能を設定することで、アクション実行の受諾までの操作をスムースに進めることができま
す。
図 10-56 ランタイム・タスク
ランタイム・タスク機能の詳細は、「6 章システム管理」の「ランタイム・タスク・ログ」節を参照してくださ
い。
10-3-6-4 可視化データ・サービス
可視化データ・サービスでは、様々な統計情報を csv 形式で出力することが可能です。データは、外
部の図表プログラムにインポートすることで、グラフ化も可能です。長期的にパフォーマンスの統計情報
を取得することで、キャパシティー・プランニングに利用することができます。取得できるログは、下記表
の通りです。
表 10-57 可視化データ・サービスで取得できるログ
ログ名
BusinessGridStatsCache
DeploymentTargetStatsHistoricCache
NodeStatsHistoricCache
ServerStatsCache
TCModuleInstanceStatsCache
TCModuleStatsCache
TierStatsCache
FineGrainedPowerConsumptionStatsCache
ServerPowerConsumptionStatsCache
説明
ビジネス・グリッド統計情報
デプロイメント・ターゲット（アプリケーション・サーバー、クラ
スター）の統計情報
ノードに関する統計情報
サーバー（各プロセスごと）の統計情報
トランザクション・クラス・モジュール・インスタンスの統計情
報
トランザクション・クラス・モジュールに関する統計情報
アプリケーションレイヤー以外の統計情報
セル・ノードの処理能力および作業量の統計情報
サーバー・レベルの
FineGrainedPowerConsumptionStatsCache と、いくつかの
追加のサーバー・データを統合したもの
可視化データ・サービス機能の詳細は、「6 章システム管理」の「可視化データ・サービス」節を参照し
てください。
また、IBM が提供する問題判別ツールである IBM Support Assistance を利用したパフォーマンス情報
の解析や、HealthCenter による Java ヒープのリアルタイム・モニタリングの説明については、「11 章問題
判別」を参照してください。
10-4 動的キャッシュ
Web システムのパフォーマンスを向上させる 1 つの手法にキャッシングがあります。しかし、近年の
Web サイトではより質の高いサービスを提供するために、動的なページ生成が主流となり、従来の静的
コンテンツのキャッシュに加えて、動的に生成されるコンテンツをサーバー・サイドでキャッシュすること
で、サーバーの負荷を軽減する重要性が増しています。WAS では、V4 以降、動的コンテンツをキャッシ
ュする動的キャッシュ機能をサポートしています。この節では、動的キャッシュ機能についての説明、お
よびその設定手順について説明します。
10-4-1 キャッシュされるコンテンツ
動的キャッシュ機能をより有効に活用するためには、キャッシュすべきコンテンツの決定や、Web ペー
ジのデザインが重要になります。
多くの場合、動的コンテンツのページの中身は、より小さい単位での静的コンテンツなどのコンポーネ
ントを組み合わせて生成されています。例えば、図 10-58 のような株のポートフォーリオを表示するペー
ジを例にとると、ページ全体としては個人ユーザー向けに生成されていても、個々の銘柄情報に関する
データベースへの問い合わせ結果や、共通のヘッダーやフッターなどをキャッシュすることで、多くのユ
ーザー向けのページを生成する際に再利用することができます。特にデータベース・アクセスは比較的
負荷が高い処理のため、データベースへの問い合わせ結果をキャッシュすることでパフォーマンスを大
幅に向上させることができます。WAS ではサーブレットや JSP の実行結果およびオブジェクト自体をキ
ャッシュすることで、さまざまな粒度でキャッシュを活用することが可能です。
キャッシュさせるデータはある程度の有効期間があるものや、有効期間は短くても多くのリクエストに
再利用できるものが最適です。
図 10-58 株のポートフォーリオ・ページ
10-4-2 動的キャッシュ・サービス
動的キャッシュ機能とは、JSP やサーブレットなどの動的コンテンツを WAS 上にキャッシュする機能で
す。この機能を利用することで、アプリケーション・サーバーおよびデータベース・サーバーなどのバック
エンド・サーバーの負荷を軽減し、クライアントに対するレスポンス・タイムを短縮することが可能となりま
す。
動的キャッシュ・サービスは、アプリケーション・サーバーの Java 仮想マシン（JVM）内で動作し、オブ
ジェクトの出力を保管したり、キャッシュからそのオブジェクトを提供したりします。キャッシュされたオブジ
ェクトはキャッシュ・エントリーと呼ばれ、JVM ヒープに保管されます。また、キャッシュは同一複製ドメイン
内に所属するアプリケーション・サーバー間で共有することが可能です。
WAS V8.5 の動的キャッシュでは、以下のキャッシュをサポートします。
•
サーブレット/JSP キャッシュ
•
コマンド・キャッシュ
•
オブジェクト・キャッシュ
•
Web サービス・クライアント・キャッシュ
•
Web サービス・キャッシュ
アプリケーション・サーバー
Webサー
バー
Web
ブラウザー
キャッシュ
キャッシュ
Web アプリケーション
プロキシー・
サーバー
図 10-59 動的キャッシュ
キャッシュ可能なオブジェクトやキャッシュの振る舞いは 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 サービスの応答をキャッシュします。
10-4-3 キャッシュのロケーション
キャッシュを活用する際には、前述の何をどの粒度でキャッシュするかといった決定に加えて、どこで
キャッシュするかが重要となります。コマンド・キャッシュやオブジェクト・キャッシュはアプリケーション・サ
ーバー上の動的キャッシュ・サービスによってキャッシュされますが、サーブレット・キャッシュはアプリケ
ーション・サーバー上の他に、外部の Web サーバーやキャッシュ・サーバーにキャッシュさせることが可
能です。外部キャッシュ上ではキャッシュ・エントリーは URI に基づいて管理されます。
一般的に、よりクライアント・サイドに近い外部キャッシュ上でキャッシュされるほうがレスポンス・タイム
を向上し、サーバー・サイドの負荷を減らすことが可能ですが、キャッシュするコンテンツによっては、個
人情報や機密情報、認証が必要な情報などを含み、セキュアなロケーションに配置する必要がありま
す。そのため、一般的には、ユーザーの固有情報や機密情報などを含むデータは認証サーバーの背
後やセキュアなゾーンにキャッシュします。
図 10-60 は、Web システムを形成する典型的な層構成と、各層でのキャッシュ可能なコンテンツを示
しています。動的キャッシュは、WAS が配置されるプレゼンテーション層やビジネス・ロジック層で使用さ
れますが、WAS 外部にキャッシュ・エンジンを配置して、動的キャッシュ・プロバイダーとして利用するこ
とも可能です。その他は外部キャッシュとして、下記のコンポーネントにキャッシュを配置可能です。
•
•
動的キャッシュ

プレゼンテーション層

ビジネス・ロジック層

外部キャッシュ・エンジン
外部キャッシュ例

Web サーバー・プラグインの ESI キャッシュ

WebSphere Proxy Server
図 10-60 キャッシュのロケーション
WAS 上 の 動 的 キ ャ ッ シ ュ の キ ャ ッ シ ュ ・ エ ン ジ ン と し て 、 WebSphere eXtreme Scale (WXS) や
DataPower XC10 などの製品を利用することが可能です。データベースやホストシステムなどデータの取
得に時間やリソースが必要な場合に、その結果をインメモリー・キー・バリュー・データストアにキャッシュ
することで、パフォーマンスを向上することができます。WXS や XC10 を使用することで、個々の WAS
のアプリケーション・サーバーごとに動的キャッシュで管理するのと比較して、クラスター全体でキャッシ
ュ・データを一元管理することができます。なお、WXS は WAS V8.5.5 から Base 及び Network
Deployment エディションに同梱されています。
10-4-4 キャッシュ・インスタンス
キャッシュを保持する領域をキャッシュ・インスタンスと呼びます。キャッシュ・インスタンスは動的キャッ
シュ・サービスがデータを保管し、取り出し、共有するためのロケーションを提供します。キャッシュ・イン
スタンスは複数定義することが可能であり、キャッシュ・インスタンス毎に JNDI 名を定義します。これらの
キャッシュ・インスタンスは、独立して存在し、他のキャッシュ・インスタンスの影響を受けません。またキャ
ッシュ・インスタンスごとにキャッシュ・サイズやキャッシュ・エントリーの優先順位、ディスク・オフロードの
有無などを設定できます。
アプリケーション・サーバー上で稼動するアプリケーションは、アプリケーション・サーバーが同一複製
ドメインに所属していれば他のアプリケーション・サーバー上のキャッシュ・インスタンスにアクセスするこ
とも可能です。WAS V8.5 では 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 V8.5 Information Center を参
照して下さい。
WAS V8.5 Information Center 「動的キャッシュ用の DistributedMap および DistributedObjectCache
インターフェースの使用」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/ae/tdyn_distmap.html
10-4-5 キャッシュの複製
クラスタリング化されたアプリケーション・サーバー間でキャッシュ・エントリーを共有する機能がキャッ
シュの複製機能です。キャッシュ・エントリーを複数のアプリケーション・サーバー間で共有することで、キ
ャッシュのヒット率を向上させることが可能です。キャッシュの複製にはデータ・レプリケーション・サービ
ス（以下 DRS）が使用されます。キャッシュを共有するアプリケーション・サーバーは同じ複製ドメインに
所属する必要があります。なお、DRS はセッション・オブジェクトの複製にも使用することができますが、
動的キャッシュの複製に使用するドメインとセッション・オブジェクトの複製に使用するドメインは分けるこ
とが推奨されます。これは、セッション・オブジェクトの複製と動的キャッシュの複製では、複製先の数が
異なるためです。セッション・オブジェクトは必ずしも全サーバーに複製する必要はありませんが（オリジ
ナル以外に最低 1 つ以上存在すればよい）、動的キャッシュはすべてのアプリケーション・サーバーに
複製を配置する必要があるからです。
10-4-6 キャッシュの無効化
キャッシュを使用する上で非常に重要なのは、いつキャッシュを無効化するかです。キャッシュとオリ
ジナルのコンテンツやキャッシュの元となるデータベース上などのデータとの一貫性を保持することが大
前提となります。従来の静的コンテンツのキャッシュのようにあらかじめ想定した有効期限を設定する方
式では、データの整合性を厳密に管理できないため、オリジナルのコンテンツやデータ対する変更をトリ
ガーに、関連するキャッシュを無効化しキャッシュ・インスタンスから削除する仕組み（キャッシュの無効
化）が必要になります。WAS V8.5 では、以下の方法で動的キャッシュの無効化をサポートします。
•
時間ベース
キャッシュが作成されてから指定する秒数を経過することによるエントリーの削除
•
グループ・ベース (依存関係 ID による無効化)
作成されたキャッシュを cachespec.xml ファイルを使用して、Dependency ID（依存 ID）規則により
グループ化し、任意のタイミングでグループ単位にエントリーを削除
•
LRU ルール・ベース
キャッシュ・インスタンス内のキャッシュ・エントリーが溢れた際に Least Recently Used（以下 LRU）
ルールによる最も使われていないエントリーを削除
•
Java コーディング
com.ibm.websphere.cache.DistributedMap インターフェースに定義されたメソッドを呼び出すこと
による削除
10-4-7 ディスク・オフロード
同時に保存されるキャッシュ・サイズがキャッシュに使用可能なメモリー・サイズより大きい場合には、
ディスク・オフロードの使用を検討します。
キャッシュ・インスタンスは、インスタンス毎に最大キャッシュ・サイズをエントリー数で指定することがで
きます（デフォルトは 2000 エントリー）。あらかじめキャッシュ・エントリーに優先度を設定しておくと、この
最大キャッシュ・サイズを超えた場合、キャッシュは優先順位と LRU ルールに従い、メモリーから削除さ
れます。しかし、ディスク・オフロード機能を使用すると、メモリーから削除されるキャッシュ・エントリーを
ディスク上に退避させておくことが可能となります。ディスクに退避されたキャッシュ・エントリーに対する
アクセスが発生すると、そのキャッシュ・エントリーは再びメモリー上にロードされ、別のキャッシュ・エント
リーが LRU ルールにしたがってディスクへと退避されます。なお、頻繁にアクセスされるキャッシュ・エン
トリーは常にメモリー上においておくために、高い優先順位をつけておくことが推奨されます。
10-4-8 cachespec.xml ファイル
動的キャッシュでのキャッシュ方法に関する動作は、cachespec.xml ファイルによって定義されます。
cachespec.xml では、キャッシュ可能オブジェクトとそのキャッシュ方法を定義します。また、キャッシュ・エ
ントリー間の依存関係やタイムアウト、無効化に関してのポリシーもこのファイルで定義します。キャッシュ
可能なオブジェクトは、<cache-entry>エレメントで定義し、各キャッシュ・エントリーに対して、どこにキャッ
シュするか(WAS のどのキャッシュ・インスタンス上か、外部キャッシュ上かなど)、どのような情報をもとに
キャッシュを区別してキャッシュしていくか（どのようにキャッシュ ID を生成するか）、キャッシュの無効化
をどのようにして行うか（どの依存 ID を使ってキャッシュをグルーピングしグループ単位で無効化する）
などを定義します。
cachespec.xml ファイルは、アプリケーション・サーバーの開始時およびファイルが変更されたときに動
的に読み込まれます。動的キャッシュ・サービスは、新しいサーブレットやキャッシュ可能なオブジェクト
が初期化されるたびに、この記述を元に、キャッシュを行い、キャッシュ ID を生成します。
cachespec.xml ファイルはアプリケーションのデプロイメント・モジュール内に同梱することも、グローバ
ル・レベルでの設定として<Profile_root>/properties ディレクトリーに配置することも可能ですが、アプリ
ケーションのメンテナンスを考慮して以下のデプロイメント・モジュール内に配置することが推奨されま
す。
•
モジュール・レベルでの設定

Web モジュールの WEB-INF ディレクトリー

EJB モジュールの META-INF ディレクトリー
10-4-9 動的キャッシュの設定
ここでは、動的キャッシュの種類毎に設定方法を説明します。
サーブレット・キャッシュ
動的キャッシュ・サービスの有効化 [10-4-9-1]
キャッシュ・インスタンスの作成（オプション） [10-4-9-2]
cachespec.xml ファイルによるキャッシュ・ポリシーの定義 [10-4-9-9]
無効化ロジックのアプリケーションへの作りこみ（オプション）
WAS V7.0 以降では、ポートレット・キャッシングが追加され、ポートレットが呼び出された際にキャッシ
ュ・エントリーを作成することが可能です。ポートレット・キャッシングを使用可能とすると、自動的にサー
ブレット・キャッシュが使用可能になります。
コマンド・キャッシュ
1).
WebSphere Command Framework に基づいたアプリケーションの開発
動的キャッシュ・サービスの有効化 [10-4-9-1]
キャッシュ・インスタンスの作成（オプション）[10-4-9-2]
cachespec.xml ファイルによるキャッシュ・ポリシーの定義 [10-4-9-9]
オブジェクト・キャッシュ
1).
DistributedMap インターフェースを用いたアプリケーションの開発
動的キャッシュ・サービスの有効化 [10-4-9-1]
キャッシュ・インスタンスの作成（オプション） [10-4-9-2]
以降ではそれぞれのステップでの設定内容を説明します。
10-4-9-1 動的キャッシュ・サービスの有効化
動的キャッシュ・サービスはデフォルトで使用可能になっています。
1).
管理コンソールのツリー･ビュー上で、[サーバー]→[サーバー・タイプ]→[WebSphere Application
Server]→[AppServer_name]を選択します。
サーバーの管理画面で、[コンテナー設定]→[コンテナー・サービス]下の[動的キャッシュ・サービス]を
選択します。
サーブレッド・キャッシングを使用可能にする場合には[Web コンテナー]を、ポートレット・キャッシン
グを使用可能にする場合には[ポートレット・コンテナー]を選択して下さい。
図 10-61 動的キャッシュ・サービスの設定
また、この画面では、キャッシュ・サイズのエントリー数やデフォルト優先順位、およびディスク・オフロ
ードの設定が可能です。キャッシュ・サイズに関しては 10-4-9-5、ディスク・オフロードの設定に関しては
10-4-9-6 を参照して下さい。ここで設定した内容はグローバル設定として扱われ、動的キャッシュ・サー
ビスのデフォルトでの設定値となります。キャッシュ・インスタンス単位や cachespec.xml ファイルで個別に
設定するとその内容で上書することが可能です。なお、動的キャッシュ・サービスに設定された内容は、
アプリケーション・サーバーを再起動するまで有効になりません。
10-4-9-2 キャッシュ・インスタンスの作成
キャッシュ・インスタンスを作成するには、使用したい動的キャッシュに合わせて作成するキャッシュ・イ
ンスタンスの種類（オブジェクト・キャッシュ・インスタンス、サーブレット・キャッシュ・インスタンス）を指定し
ます。例えば、サーブレット・キャッシュの場合は、管理コンソールのツリー・ビュー上で、[リソース]→[キ
ャッシュ・インスタンス]→[サーブレット・キャッシュ・インスタンス]を選択します。
キャッシュ・インスタンスはセル、ノード、クラスター、サーバーの各レベルで設定可能です。設定したレ
ベルにより、キャッシュ・インスタンスの JNDI 名の解決に影響がありますので注意して下さい。
図 10-62 は、クラスター・レベルでの設定例になります。
図 10-62 キャッシュ・インスタンス設定の有効範囲
キャッシュ・インスタンスの設定画面では、以下を設定します。
•
名前： キャッシュ・インスタンスの管理用の名前
•
JNDI 名： アプリケーションからルックアップする時に使用する JNDI 名
•
キャッシュ・サイズ： 最大キャッシュ・エントリー数
その他、このキャッシュ・インスタンス単位でのディスク・オフロード（10-4-9-6 ディスク・オフロードの設
定(p.84)」参照）や複製の設定（「10-4-9-8 キャッシュの複製(p.88）」参照）もこの画面から設定可能で
す。なお、キャッシュ・インスタンスの作成はオプションで、キャッシュ・インスタンスを明示的に作成しない
場合はデフォルトのキャッシュ・インスタンスが作成され、使用されます。
図 10-63 キャッシュ・インスタンスの設定
10-4-9-3 サーブレット・キャッシングの設定
サーブレット・キャッシングの設定は、サーブレット・キャッシングを有効にしたいアプリケーション・サー
バーごとに行います。管理コンソールから[サーバー]→[サーバー・タイプ]→[WebSphere Application
Server]→[ApplicationServer_name]→[Web コンテナー設定]→[Web コンテナー]→[サーブレットおよ
びコマンドのキャッシュを使用可能にする]をチェックします。
これらの設定はサーブレット・キャッシングを行うすべてのアプリケーション・サーバーに対して行いま
す。また、設定はアプリケーション・サーバーを再起動するまで有効になりません。
図 10-64 サーブレット・キャッシュの設定
10-4-9-4 ポートレット・キャッシングの設定
ポートレット・キャッシングの設定はポートレット・キャッシングを有効にしたいアプリケーション・サーバ
ーごとに行います。管理コンソールから[サーバー]→[サーバー・タイプ]→[WebSphere Application
Server]→[ApplicationServer_name]→[ポートレット・コンテナー設定]→[ポートレット・コンテナー]→[ポ
ートレット・フラグメント・キャッシュを使用可能にする]をチェックします。
これらの設定はポートレット・キャッシングを行うすべてのアプリケーション・サーバーに対して行いま
す。また、設定はアプリケーション・サーバーを再起動するまで有効になりません。
図 10-65 ポートレット・キャッシングの設定
10-4-9-5 キャッシュ・サイズの設定
WAS の動的キャッシュでは、キャッシュされたオブジェクトを JVM メモリーに保管します。キャッシュに使
用できるメモリーのサイズからキャッシュに保管可能な最大エントリー数を決定し、キャッシュ・サイズに設
定します。キャッシュ・サイズ（デフォルト値：2000）には 100 から 200,000 の整数を指定することができま
すが、キャッシュ自体はメモリー上に保管されるため、キャッシュに使用可能なメモリー領域から、キャッ
シュされる個々のエントリーのサイズを元に適切な最大エントリー数を決定して下さい。また、WAS V8.5
では、キャッシュ・サイズを指定することで、キャッシュによる JVM メモリーの使用量を制限することが出
来ます。
図 10-61 動的キャッシュ・サービスの設定 (p.80)」の設定画面でデフォルトのキャッシュ・インスタンス
に対してキャッシュ・サイズを指定するか、「図 10-63 キャッシュ・インスタンスの設定 (p.81)」の設定画
面で個々のキャッシュ・インスタンスに個別に設定することもできます。
表 10-3 キャッシュ・サイズの設定
項目
キャッシュ・サイズ
メモリー・キャッシュ・
サイズの制限
メモリー・キャッシュ・
サイズ
高しきい値
説明
キャッシュが保持するエントリー数を指定します。
デフォルト値：2000
メモリー・キャッシュ・サイズを使用するか、使用しないかを指定します。
メモリーのキャッシュ・サイズを MB 単位で指定します。
キャッシュ・サイズが高しきい値に達すると、動的キャッシュにより、低しきい値
に下がるまで、サイズを調整します。
デフォルト値：95%
低しきい値
デフォルト値：80%
なお、ディスク・オフロードの設定を行うことで、キャッシュ・サイズを超えたエントリーをディスクに退避
させることも可能です。設定手順については、「10-4-9-6 ディスク・オフロードの設定 (p.84)」を参照して
下さい。
10-4-9-6 ディスク・オフロードの設定
ディスクのオフロード機能を使用する場合は、キャッシュ・インスタンスに対して設定を行います。デフォ
ルトのキャッシュ・インスタンスを使用する場合は、 [サーバー]→[WebSphere Application Server]→
[ApplicationServer_name]→[コンテナー・サービス]→［動的キャッシュ・サービス] を選択し、「
図 10-61 動的キャッシュ・サービスの設定 (p.80)」から下記設定を行います。個々のキャッシュ・インスタ
ンスに対して設定を行う場合は、[リソース]→[キャッシュ・インスタンス]→[オブジェクト・キャッシュ・インス
タンス（またはサーブレット・キャッシュ・インスタンス）]→[<CacheInstance_name>]を選択します。以下、
主な設定項目について、説明します。
表 10-4 ディスク・オフロードの設定
項目
ディスク・オフロードを
使用可能にする
オフロード位置：
ディスクへのフラッシュ
ディスク・キャッシュ・サ
イズ (GB) の制限
ディスク・キャッシュ・サ
イズの制限 (エントリ
ー数)
説明
ディスク・オフロードの使用可能の有無を設定します。ディスクにオフロードさ
れたキャッシュ・エントリーは、再度必要になると、ファイル・システムからメモリ
ーに戻されます。
ディスクに保管されるキャッシュ・エントリーの保管場所を指定します。オフロー
ド位置を省略した場合は、下記が使用されます。
<WAS_root>/diskoffload/Node_name/ApplicationServer_name/_dynacache/<C
acheJNDI_name>
保管場所を指定した場合は、ノード名、サーバー名およびキャッシュ・インスタ
ンス名が自動的に追加されます。例えば、”<WAS_root>/diskoffload” を指定
した場合、実際には下記が使用されます。
<WAS_root>/diskoffload/Node_name/ApplicationServer_name/<CacheJNDI_n
ame>
この値は、ディスク・オフロードが無効にされている場合は無視されます。
サーバーの停止時に、メモリー内のキャッシュ・オブジェクトをディスクに保管
する場合に選択します。このオプションを選択する場合は、ディスク・オフロー
ド機能を使用可能にする必要があります。また、ディスクへのフラッシュ機能を
使用しない場合は、サーバーの停止時にすべてのキャッシュ・オブジェクトが
削除されます。
最大ディスク・キャッシュ・サイズの値を GB 単位で指定します。このオプショ
ンを選択した場合は、正整数の値を指定できます。 このオプションをブランク
にしておくことは、サイズを無制限とすることを示します。 この設定は、キャッシ
ュの「ディスク・オフロードを使用可能にする」が指定されている場合にのみ適
用されます。
最大ディスク・キャッシュ・サイズの値をエントリー数で指定します。このオプショ
ンを選択した場合は、正整数の値を指定できます。 このオプションをブランク
にしておくことは、サイズを無制限とすることを示します。 この設定は、キャッシ
ュの「ディスク・オフロードを使用可能にする」が指定されている場合にのみ適
ディスク・キャッシュ・エ
ントリー・サイズの制限
パフォーマンス設定
ディスク・キャッシュ・ク
リーンアップの頻度
メタエントリーごとのキ
ャッシュ ID の最大バ
ッファー
依存 ID の最大バッ
ファー
テンプレートの最大バ
ッファー
排除ポリシー
アルゴリズム
用されます。
個々のディスク・キャッシュ・エントリーの最大サイズの値を MB 単位で指定し
ます。 これより大きいキャッシュ・エントリーは、メモリーから除去される際、ディ
スクにオフロードされません。 このオプションを選択した場合は、正整数の値
を指定できます。 このオプションをブランクにしておくことは、サイズを無制限
とすることを示します。 この設定は、キャッシュの「ディスク・オフロードを使用
可能にする」が指定されている場合にのみ適用されます。
・ハイパフォーマンスと高位メモリー使用率
すべてのメタデータをメモリー内に保持します。
・平衡パフォーマンスと平衡メモリー使用率
メタデータの一部をメモリー内に保持します。
・ローパフォーマンスと低位メモリー使用率
限られたメタデータをメモリー内に保持します。
・カスタム
以下の設定項目を指定します。
メタエントリーごとのキャッシュ ID の最大バッファー
依存 ID の最大バッファー
テンプレートの最大バッファー
ディスク・キャッシュ・クリーンアップの頻度
ディスク・キャッシュ・クリーンアップの頻度を分単位で指定します。値を”0”に
設定した場合、クリーンアップは深夜 12 時に実行され、期限切れのキャッシ
ュ・エントリーおよび過去 24 時間の間にアクセスされなかったキャッシュ・エント
リーを除去します。例えば”60”に設定すると、60 分おきにクリーンアップが実
施されます。また、ディスク・オフロードのパフォーマンス・レベルが「ロー」、「平
衡」、または「カスタム」の場合にのみ適用されます。ハイパフォーマンス・レベ
ルでは、ディスクのクリーンアップが必要ではないため、この設定値は無視さ
れます。
メモリー内のディスク・キャッシュ・メタデータの、個々の依存 ID またはテンプレ
ートに保管されるキャッシュ ID の最大値を指定します。この最大値を超える
と、ディスクにオフロードされます。
メモリー内のディスク・キャッシュ・メタデータの依存 ID バケットの最大値を指定
します。この最大値を超えると、ディスクにオフロードされます。
メモリー内のディスク・キャッシュ・メタデータに存在するテンプレート・バケット
の最大値を指定します。この最大値を超えると、ディスクにオフロードされま
す。
高しきい値に達した場合にキャッシュ・エントリーを除去する、ディスク・キャッシ
ュが使用するアルゴリズムを指定します。
・なし
動的キャッシュ・サービスがディスクへの書き込みを停止するまで、ディスク・
キャッシュを拡張する可能性があります。
・ランダム
ディスク・サイズが高しきい値に達した場合、ディスク・キャッシュのガーベッ
ジ・コレクターが起動し、ディスク上のエントリーをランダムに選択して、サイズ
が低しきい値に達するまで除去します。
・サイズ
ディスク・サイズが高しきい値に達した場合、ディスク・キャッシュのガーベッ
高しきい値
低しきい値
ジ・コレクターが起動し、ディスク上の最も大きいエントリーを選択し、ディスク・
サイズが低しきい値に達するまで除去します。
除去ポリシーを実行開始するしきい値を、GB 単位、もしくはディスク・サイズに
対するエントリー数のパーセンテージを指定します。
除去ポリシーを実行終了するしきい値を、GB 単位、もしくはディスク・サイズに
対するエントリー数のパーセンテージを指定します。
図 10-66 ディスク・オフロードの設定
10-4-9-7 ディスク・オフロードのチューニング
ディスク・オフロード機能では、パラメーターを使ったチューニング項目があります。これらのパラメータ
ーはカスタム・プロパティーとして設定します。チューニングは、すべてのキャッシュ・インスタンスにわた
って設定することもキャッシュ・インスタンス単位で設定することも可能です。
なお、ディスク・オフロードを使用する際には、ディスク書き込みのパフォーマンスを最適化するために
ファイル・システムやディスク装置のチューニングも同時に行って下さい。すべてのキャッシュ・インスタン
スに対してのカスタム・プロパティーを設定するには以下のステップを実行します。
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”に設定
した場合、すべてのキャッシュ・エントリーはメモリー・キャッシュから除去されると即時にディス
クにコピーされます。
10-4-9-8 キャッシュの複製
キャッシュの複製機能では、一度作成されたキャッシュ・データをクラスター内の他のアプリケーショ
ン・サーバーに複製します。この機能により、複数アプリケーション・サーバーで同じ要求を実行する実
行時間や実行中に使用するリソースを節約することが可能となります。また、キャッシュの複製は、無効
化機能もサポートしているため、複数アプリケーション・サーバー間でのキャッシュの一貫性を保つことが
できます。ここでは、以下の設定手順を説明します。
1).
複製ドメインの作成
2).
キャッシュの複製の設定
キャッシュの複製には、データ・レプリケーション・サービスが使用されます。キャッシュの複製を使用
するためには、まずは複製ドメインを作成します。管理コンソールのツリー・ビュー上から、[環境] →[複
製ドメイン] を選択し、複製ドメインの設定画面で[新規作成] ボタンを押します。
エラー! 参照元が見つかりません。では、作成する複製ドメインの名前、要求タイムアウト、暗号化の
有無などを設定します。またここで、レプリカの数は必ず[ドメイン全体]を選択します。これはキャッシュの
複製では、クラスター内の他のアプリケーション・サーバー全てに対して複製を行うためです。
図 10-67 複製ドメインの作成
次にキャッシュの複製の設定を行います。以下の手順で設定します。
1).
管 理 コ ン ソ ー ル の ツ リ ー ・ ビ ュ ー 上 か ら 、 [ サ ー バ ー ]→[ サ ー バ ー ・ タ イ プ ]→[WebSphere
Application Server]から設定したい[ApplicastionServer_name]を選択します。
2).
[コンテナー・サービス]→[動的キャッシュ・サービス]を選択します。
3).
図 10-68 で[キャッシュ複製を使用可能にする]をチェックし、[フル・グループ複製ドメイン]には先
ほど作成した複製ドメインを指定します。
4).
図 10-68 でさらに複製タイプと[push 頻度]を設定します。（詳細は後述します）
5).
上記ステップ 1)-4)を、キャッシュの複製を行うすべてのアプリケーション・サーバーに対して行いま
す。
6).
設定が終了したら構成を保存します。
図 10-68 キャッシュ複製の設定
なお、キャッシュの複製の設定は、キャッシュ・インスタンス毎に異なる設定を行うこともできます。キャ
ッシュ・インスタンス単位で設定する場合は、使用しているキャッシュ・インスタンスの一般プロパティー画
面から同様の設定を行います。
複製タイプの設定
[複製タイプの設定]には以下のモードが設定可能です。
•
push と pull の両方
キャッシュは必要に応じてコピーされます。アプリケーション・サーバーは、キャッシュ・エントリーを
作成すると、複製ドメイン内の他のアプリケーション・サーバーに新しく更新されたコンテンツのキャ
ッシュ ID を送ります。各アプリケーション・サーバーはクライアントからの要求を受け取ると、その要
求に対するキャッシュ ID が存在するかをあらかじめ把握しているため、キャッシュ・コンテンツを保
持するサーバーからコンテンツを受け取るか、存在しない場合は自身で要求を処理して新しいキ
ャッシュ ID を生成します。
•
pull のみ
この複製タイプの設定は推奨されていませんので、ご注意下さい。必要に応じて、このオブジェクト
に対するキャッシュ・エントリーを、複数のアプリケーション・サーバー間で共用します。アプリケー
ション・サーバーが、このオブジェクトのキャッシュを確認できなかった場合、他のアプリケーション・
サーバーに確認します。どのアプリケーション・サーバーでも、このオブジェクトのキャッシュされた
コピーを確認できない場合、オリジナルのアプリケーション・サーバーがリクエストを実行しオブジェ
クトを生成します。
•
push のみ
キャッシュ ID およびそのコンテンツは、自動的に複製ドメイン内のすべてのアプリケーション・サー
バーに複製されます。したがって、全てのアプリケーション・サーバー内にキャッシュ・エントリーの
複製が常に置かれることになります。
•
共有しない
キャッシュおよびキャッシュ ID は、アプリケーション・サーバー間で共有されません。
push 頻度
[push 頻度]には、新しいキャッシュ・エントリーや更新されたエントリーを他のサーバーに送信する頻
度を秒で指定します。”0”に設定された場合、キャッシュ・エントリーは即座に送信されます。”0”より大き
い値を設定すると、その間に作成または変更された全てのキャッシュ・エントリーがバッチ的に送信され
ます。ただし、キャッシュの無効化はここで設定した秒数とは別に即座に実行されます。
cachespec.xml によるキャッシュ・ポリシーの定義
前項で設定したキャッシュ複製の設定は、cachespec.xml ファイルで設定した内容で上書きすることが
できます。cachespec.xml ファイルの各エントリーには<sharing-policy>エレメントを使用してキャッシュ複
製の設定を行うことができます。これにより、個々のエントリー単位でキャッシュ複製の設定を変更するこ
とが可能です。<sharing-policy>の値には 4 つのタイプが指定できます。詳細は「10-4-9-9 cachespec.xml
によるキャッシュ・ポリシーの定義」を参照して下さい。なお、<sharing-policy>が設定されていないエント
リーに対しては、グローバル設定が適用されます。
10-4-9-9 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.91）」を参照して下さい。
3).
キャッシュ ID の生成ルールを作成します。詳細については Cachespec.xml ファイルの記述（p. 91）」
を参照して下さい。
4).
(オプション)依存関係 ID ルールを指定します。
<dependency-id>エレメントを使用してキャッシュ・グループ ID を指定します。この ID は、複数のキ
ャッシュ・エントリーを同じグループ ID に関連つけます。
5).
（オプション）無効化 ID 生成ルールを指定します。
無効化 ID は、依存関係 ID と同じ方法で定義されます。
6).
cachespec.xml ファイルを保管します。動的キャッシュ・サービスは更新済みファイルを自動的に再
ロードしますが、古いポリシー・ファイルによってキャッシュに保管されたオブジェクトは、ファイルの
更新によって無効化はされません。これらのオブジェクトは新規ポリシーにより再利用されるか、あ
るいは置換アルゴリズムによってキャッシュから除去されます。
Cachespec.xml ファイルの記述
ここでは、cachespec.xml ファイルの中から主要なエレメントについて説明します。全エレメントの詳細
については、InfoCenter を参照して下さい。
WAS V8.5 Information Center 「cachespec.xml ファイル」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/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
「10-4-9-8 キャッシュの複製 (p. 88)」で設定したキャッシュ複製のグローバル設定は、cachespec.xml
ファイルを使って個々のキャッシュ・エントリーごとに上書き設定することができます。cachespec.xml ファ
イルの各エントリーには<sharing-policy>エレメントを使用してキャッシュ複製の設定を行うことができま
す。<sharing-policy>の値には以下の 4 つのタイプが指定でき、クラスター構成においてキャッシュの複
製に関するポリシーを指定します。デフォルト値は”not-shared”で、また<sharing-policy>エレメントが記
述されていない時にもこの値が適用されます。スタンドアロン・サーバー環境では、”not-shared”のみが
有効です。
表 10-5 キャッシュ複製タイプ
ポリシー
Not-shared
サーバー間
での連携
×
メモリーの利
用効率
－
動作
キャッシュが生成されたアプリケーション・サーバーのみ
でキャッシュを保持し共有はされない。デフォルト値。特
定ユーザーが複数回使用するキャッシュに使用。
Shared-push
○
△
Shared-pull
○
○
Shared-pushpull
○
○
キャッシュのエントリーが生成されると他のアプリケーシ
ョン・サーバーにエントリーとキャッシュ ID を自動的に配
布。常に各サーバー上にキャッシュのコピーが作成され
る。耐障害性は高いがすべてのサーバーにキャッシュ
が配置されるのでリソースを多く使用する。多くのユー
ザーに使われ、かつヒット率も高いキャッシュに使用。
アプリケーション・サーバーは自身のキャッシュにオブジ
ェクトが存在しない場合、他のアプリケーション・サーバ
ーに照会してキャッシュが存在するかを調べる。どのサ
ーバーにもキャッシュが存在しない場合は自分で処理
を行う。
キャッシュが作成されるとキャッシュ ID のみを他のアプリ
ケーション・サーバーに配布。これにより、アプリケーショ
ン・サーバーは特定のキャッシュ ID に対するエントリー
をどのアプリケーション・サーバーにとりに行けばよい
か、または自分で処理を実施すべきかを判断できる。
<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>と同じです。
10-4-9-10 cachespec.xml 記述例
「10-4-9-9cachespec.xml によるキャッシュ・ポリシーの定義 (p. 90)」で説明した cachespec.xml の記述
例を紹介します。例としてここでは Trade アプリケーションを使用します。Trade アプリケーションとは WAS
の ベ ン チ マ ー ク 用 ア プ リ ケ ー シ ョ ン で 、 以 下 の サ イ ト か ら 入 手 可 能 で す 。
http://www-01.ibm.com/software/webservers/appserv/was/performance.html
Trade アプリケーションの中で Trade6 アプリケーションは、動的キャッシュ・サービスを利用しています。
以下の Web モジュールの WEB-INF ディレクトリーに Trade6 用 cachespec.xml ファイルがあります。
<Profile_root>/config/cells/<cell_name>/applications/Trade.ear/deployments/Trade/tradeWeb.war/WEBINF
ここではこの cachespec.xml ファイルの一部を紹介します。Trade アプリケーションの内容についての詳
細は、Trade アプリケーションに含まれるドキュメントを参照して下さい。また、その他のベンチマーク用ア
プリケーションとして、DayTrader アプリケーションがあり、以下のサイトから入手可能です。
http://geronimo.apache.org/
サーブレット・キャッシュの定義
「例 10-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>
例 10-1 サーブレット・キャッシュ・エントリー定義例
コマンド・キャッシュの定義
「 例 10-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>
例 10-2 コマンド・キャッシュ・エントリーの定義例
無効化の定義
「例 10-3 無効化の定義例」は、無効化のポリシーを定義しています。OrderCompletedCommand に
は無効化 ID <invalidation>として Account_UserID と Holdings_UserID が定義されています。これによ
り、OrderCompletedCommand が実行されると、Account_UserID または 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>
例 10-3 無効化の定義例
10-4-9-11 動的キャッシュの管理
Dynamic Cache Monitor とは、キャッシュの統計、キャッシュ・エントリーやキャッシュ・ポリシーに関する
情 報 を 表 示 す る ア プ リ ケ ー シ ョ ン で 、 CacheMonitor.ear フ ァ イ ル と し て 提 供 さ れ て い ま す 。
CacheMonitor.ear ファイルは、<WAS_root>/installableApps 下に配置されており、これをインストールす
ることで、以下の項目を確認することができます。
•
動的キャッシュの構成の検査
•
キャッシュ・ポリシーの検査
•
キャッシュ統計のモニター
•
キャッシュを通過するデータのモニター
•
エッジ・キャッシュ内のデータのモニター
•
ディスクにオフロードされたデータの表示
•
キャッシュ内のデータの管理
•
キャッシュからのエントリー除去
•
特定の依存関係 ID に対するすべてのエントリー除去
•
特定のテンプレートに対するすべてのエントリー除去
•
最低使用頻度キューの先頭へのエントリー移動(エントリー除去を回避する)
•
ディスクからキャッシュ・インスタンス内のメモリーへのエントリーの移動
•
キャッシュ・コンテンツ全体の消去
•
キャッシュ・インスタンスのディスクのコンテンツ消去
以降では、Dynamic Cache Monitor のインストール手順を示します。なおセキュリティーを考慮して、
通常のアプリケーションとは異なるホスト名とポート番号を使用するため、最初に仮想ホストを別途作成
します。
仮想ホストの作成
1).
管理コンソールのツリー・ビュー上から、[環境]→[仮想ホスト]を選択し[新規作成]ボタンを押しま
す。
2).
名前に仮想ホストの名前（ここでは”cache_monitor”を指定）を設定し、[適用]ボタンを押します。
3).
追加プロパティーの[ホスト別名]→[新規作成]ボタンを押し、ホスト名に”*”（アスタリスク）、ポートに
任意のポート番号（キャッシュ管理の目的に使用するポート番号。ここでは”9070”を使用）を設定
し、[OK]ボタンを押し、構成を保存します。
図 10-69 仮想ホストの作成
4).
次にアプリケーション・サーバーの Web コンテナーの Inbound Chain を作成します。管理コンソール
の ツ リ ー ・ ビ ュ ー 上 で 、 [ サ ー バ ー ]→[ サ ー バ ー ・ タ イ プ ]→[WebSphere Application
Server]→[ApplicationServer_name]→[Web コンテナー設定]→[Web コンテナー・トランスポート・
チェーン]を選択し、[新規作成]ボタンを押します。
5).
トランスポート・チェーン名に任意の名前（ここでは”CacheMonitor”を指定）を設定し、[次へ]ボタン
を押します。
6). ポート名には任意の名前（ここでは”9070”を使用）、ホストには”*”（アスタリスク）、ポートには 3).
で設定したポート番号（”9070”）を設定し[次へ]ボタンを押します。
図 10-70 トランスポート・チェーンの作成
7).
設定した内容を確認して[終了]ボタンを押し、構成を保存します。
8).
上記ステップ 4). 6). を Dynamic Cache Monitor を導入する全てのアプリケーション・サーバーに対
して実施します。このとき、同一ノード上で複数のアプリケーション・サーバーを稼動している場合
はポート番号が重複しないように注意して下さい。また、1). 3). で設定した以外のポート番号を使
用する場合は、都度仮想ホストの追加設定をして下さい。
Cache Monitor のインストール
次に Cache Monitor アプリケーションを監視対象サーバーに導入します。
1).
管理コンソールのツリー・ビュー上から、[アプリケーション]→[エンタープライズ・アプリケーショ
ン]→[インストール] を選択します。
2).
アプリケーション・インストールの準備画面で、CacheMonitor.ear ファイルへのパスを設定し、[次へ]
をクリックします。（デフォルトでは、<WAS_root>/installableApps の下にあります。）
3).
次の画面では、[詳細]、[デフォルト・バインディングの生成]、[Web モジュールおよび SIP モジュー
ルにデフォルト仮想ホスト名を使用する:]を選択し、[ホスト名]に先ほど作成した仮想ホストを指定
します。
図 10-71 仮想ホストの指定
4).
次のセキュリティーに関する警告ページでは[継続]をクリックします。
5).
[ステップ 1]ではデフォルトのまま[次へ]をクリックします。
6).
[ステップ 2]では[クラスターおよびサーバー]からアプリケーションをインストールするクラスターまた
はサーバーを選択し、[Dynamic Cache Monitor]モジュールを選択して[適用]ボタンをクリックしま
す。
図 10-72 導入先サーバーの設定
7).
[ステップ 6]では [Dynamic Cache Monitor]WebModule をチェックし、仮想ホストには先ほど作成し
た[cache_monitor]を選択します。
図 10-73 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 とパスワード
が必要になります。
キャッシュ・モニターにアクセスすると、図 10-74 のようなページが表示されます。ここからキャッシュに
関する統計を表示したり、キャッシュ内容(図 10-75 キャッシュ内容)を表示したり、キャッシュを操作する
ことが可能です。
図 10-74 キャッシュ・モニター画面
図 10-75 キャッシュ内容
10-4-9-12 外部キャッシュ
動的キャッシュには、サーブレット・キャッシュを WAS の外部に配置し、制御する機能があります。より
クライアントに近い場所でキャッシュ・ヒットさせることにより、レスポンスが返されるまでのホップ数が減り
応答時間も向上しますし、バックエンドのシステムにかかる負荷を軽減することにもつながります。外部キ
ャッシュの配置先としては、以下の 3 つがサポートされます。なお、二つ目の FRCA キャッシュは V7.0 よ
り非推奨になりましたので、ご注意下さい。
•
Web サーバー・プラグインの ESI プロセッサー
•
IBM HTTP Server の高速応答キャッシュ・アクセラレーター（FRCA キャッシュ）
•
Edge Components の Caching Proxy
10-4-9-13 外部キャッシュの設定
外部キャッシュを行うには、外部キャッシュ・グループを作成してキャッシュの配置先などを指定し、キ
ャッシュ・エントリーごとのキャッシュの可否などを定義します。外部キャッシュを行うために必要な定義は
以下の通りです。
1).
外部キャッシュ・グループ定義の作成
2).
外部キャッシュ・グループ・メンバーの定義
3).
Cachespec.xml ファイルでの定義
4).
各コンポーネントでの定義
以降ではステップ 1)、2)、3）および 4）に関して、ESI キャッシュの設定方法を説明します。
外部キャッシュ・グループとメンバーの定義
外部キャッシュ・グループは以下の手順で作成します。
1).
管 理 コ ン ソ ー ル の ツ リ ー ・ ビ ュ ー 上 か ら 、 [ サ ー バ ー ]→[ サ ー バ ー ・ タ イ プ ]→[WebSphere
Application Server]を選択し、設定を行うアプリケーション・サーバーをリストから選択します。
2).
構成パネルで[コンテナー・サービス]→[動的キャッシュ・サービス]を選択し、追加プロパティーの
[外部キャッシュ・グループ]を選択します。
3).
[新規作成]で外部キャッシュ・グループの名前を入力し、[OK]ボタンを押し、構成を保存します。な
お、デフォルトで ESI キャッシュ用の外部キャッシュ・グループ（EsiInvalidator）が存在しますので、
そのまま利用して下さい。
図 10-76 外部キャッシュ・グループの作成
次に外部キャッシュ・グループのメンバーを定義します。
4). 管 理 コ ン ソ ー ル のツ リ ー・ ビ ュ ー 上 か ら 、[ サ ー バ ー ] → [ サ ー バ ー ・ タ イ プ ] → [WebSphere
Application Server]→[ApplicationServer_name]→[コンテナー・サービス]→[動的キャッシ
ュ・サービス]から、先ほど作成した外部キャッシュ・グループを選択します。
5). [外部キャッシュ・グループ・メンバー]→[新規作成]を選択します。
6). アドレスには、アダプターBean が外部キャッシュに接続する際に使用するアドレス、アダプター
Bean 名には使用する Bean 名を定義します。使用する外部キャッシュに応じて表 10-6 外部キャ
ッシュ・タイプと定義するアダプター名およびアドレス」に従って定義して下さい。
図 10-77 外部キャッシュ・メンバー定義
7).
[OK]ボタンを押し、構成を保存します。
外部キャッシュ・グループ・メンバーの追加時には、使用する外部キャッシュに応じて下記の表に従っ
て定義して下さい。
外部キャッシュ
アダプター名
アドレス
ESI
com.ibm.websphere.servlet.cache.ESIInvalidatorServlet
ホスト名(：ポート)
FRCA
com.ibm.ws.cache.servlet.Afpa
ポート番号
Caching
com.ibm.websphere.edge.dynacache.WteAdapter
ホスト名：ポート番号
Proxy
表 10-6 外部キャッシュ・タイプと定義するアダプター名およびアドレス
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>
例 10-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 アプリケーションをインストールする必要はありま
せん。
図 10-78 プロキシー・サーバーの動的キャッシュ・サービスの設定
ESI キャッシュを設定し、WebSphere プロキシー・サーバーにて動的コンテンツがキャッシュされた場
合、キャッシュから応答が返されると cache.log が更新され、初回リクエスト時や有効期限が切れた動的コ
ンテンツの場合には proxy.log が更新されます。