test

Sun Java System Web Server 7.0 パフォーマンスのチューニング、サイジング、およびスケーリング

監視データに基づくサーバーのチューニング

この節では、管理コンソール、perfdump、コマンド行インタフェース、および stats-xml 経由で利用可能なパフォーマンス情報について説明します。ここでは、その情報を解析して一部のパラメータをチューニングすることで、サーバーのパフォーマンスを改善する方法について説明します。

デフォルトのチューニングパラメータはほとんどすべてのサイトに適していますが、扱うボリュームが非常に大きいサイトだけは例外です。大規模サイトでおそらく定期的に変更する必要のある設定は、スレッドプールとキープアライブの設定だけです。これらの設定を構成レベルでチューニングするには、管理コンソール、wadm コマンドのいずれかを使用します。server.xml ファイル内の要素を直接編集することでサーバーをチューニングすることも可能ですが、server.xml ファイルを直接編集すると作業が煩雑になる可能性があります。

perfdump は次のカテゴリの統計を監視しますが、これらの各カテゴリについては次の各節で説明します。ほとんどの場合、これらの統計は管理コンソール、コマンド行インタフェース、および stats-xml 出力にも表示されます。次の各節には、どの方法を使ってデータを監視するかにかかわらず、これらすべてのカテゴリのチューニング情報が含まれています。

これに加え、管理コンソール、コマンド行インタフェース、および stats-xml 経由で表示される統計情報には、perfdump の出力に含まれない別のカテゴリも含まれています。それらの統計をチューニングする方法については、次の各節で説明します。

必要な統計を表示し終わったら、管理コンソールの「パフォーマンス」タブを使用することで、サーバーのパフォーマンスに関するさまざまな側面を構成レベルでチューニングできます。管理コンソールの「パフォーマンス」タブには、次のような多数のパフォーマンスカテゴリの設定が含まれています。

また、適切な wadm コマンドを使用することによっても、チューニングパラメータの表示や設定を行えます。一般に、wadm コマンドを使ってチューニングプロパティーを設定する場合、そのプロパティーの名前は stats.xml に表示されるものと同じになります。

接続キュー情報

Web Server では、接続はまず、HTTP リスナーに関連付けられたアクセプタスレッドによって受け付けられます。アクセプタスレッドが接続を受け付け、それを接続キューに入れます。次に、要求処理スレッドが接続キュー内の接続を取り出し、その要求を処理します。詳細については、「接続処理の概要」を参照してください。

接続キュー情報には、接続キュー内のセッション数と、接続が要求処理スレッドによって受け付けられるまでの平均遅延が表示されます。

次に、perfdump でのそれらの統計の表示例を示します。

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/1853/160032
Total Connections Queued                   11222922
Average Queue Length (1, 5, 15 minutes)    90.35, 89.64, 54.02
Average Queueing Delay                     4.80 milliseconds

管理コンソールまたはコマンド行インタフェースではこれと同じ情報が異なる形式で表示されます。ただし、若干の相違はあります。次の表に、管理コンソールでサーバーインスタンスの監視情報にアクセスした際に表示される情報を示します。

表 2–2 接続キューの統計

現在の待機接続の数 

0 

待機接続の合計数 

11222922 

最近 1 分の平均接続数 

90.35 

最近 5 分の平均接続数 

89.64 

最近 15 分の平均接続数 

54.02 

最大キューサイズ 

160032 

最大キューサイズ 

1853 

オーバーフロー接続の数 

0 

消費したティック 

5389284274 

追加した接続の合計数 

425723 

現在/ピーク/制限のキュー長

Current/Peak/Limit queue length には、次の情報が順に表示されます。

チューニング

ピークキュー長 (最大キューサイズ) が制限に近くなった場合には、最大接続キューサイズを増やすことで、高負荷時に接続が無視されるのを回避できます。

管理コンソールで最大接続キューサイズを増やすには、構成の「パフォーマンス」タブ ⇒「HTTP」サブタブにある、スレッドプールの「キューサイズ」フィールドの値を変更します。デフォルトは 1024 です。

コマンド行インタフェースを使ってキューサイズを変更するには、wadm set-thread-pool-prop コマンドの queue-size プロパティーを使用します。

待機接続の合計数

Total Connections Queued は、これまで接続がキューに入れられた回数の合計値です。この数値には、新しく受け付けられた接続と、キープアライブシステムからの接続が含まれます。

この設定はチューニング不可能です。

平均キュー長

Average Queue Length には、直前の 1 分間、5 分間、および 15 分間におけるキュー内の平均接続数が表示されます。

この設定はチューニング不可能です。

平均キュー遅延

Average Queueing Delay は、接続が接続キュー内で費やす時間の平均値です。これは、ある要求の接続がサーバーによって受け付けられてから、要求処理スレッドがその要求の処理を開始するまでの遅延を表します。これは、「消費したティック」を「待機接続の合計数」で割った結果をミリ秒に変換したものになります。

この設定はチューニング不可能です。

消費したティック

ティックはシステムに依存する値であり、stats.xml 内の server 要素の tickPerSecond 属性によって提供されます。消費したティックの値は、接続が接続キュー内で費やした時間の合計であり、平均キュー遅延を計算するために使用されます。

この設定はチューニング不可能です。

追加した接続の合計数

接続キューに追加された新しい接続の数。この設定はチューニング不可能です。

HTTP リスナー (待機ソケット) 情報

次の HTTP リスナー情報には、IP アドレス、ポート番号、アクセプタスレッドの数、およびデフォルト仮想サーバーが含まれています。この HTTP リスナー情報の中で、チューニングのためにもっとも重要なフィールドは、アクセプタスレッドの数です。

仮想サーバーに対して多数の HTTP リスナーを有効にすることができますが、デフォルトサーバーインスタンスでは少なくとも 1 つのリスナー (通常は http://0.0.0.0:80) が有効になります。管理コンソール経由で利用可能な監視情報には、HTTP リスナー情報が表示されません。なぜなら、管理コンソールでは、その情報は構成の「HTTP リスナー」タブで利用可能になっているからです。

次に、perfdump での HTTP リスナー情報の表示例を示します。

ListenSocket ls1:
------------------------
Address                   https://0.0.0.0:2014
Acceptor Threads          1
Default Virtual Server    https-test

HTTP リスナーを複数個作成した場合、perfdump にはそれらがすべて表示されます。

管理コンソールを使って HTTP リスナーを編集するには、使用する構成で「HTTP リスナー」タブを選択します。リスナーの名前をクリックしてそのリスナーを編集します。

コマンド行インタフェースを使って HTTP リスナーを構成するには、コマンド wadm set-http-listener-prop を使用します。

待機ソケットを追加および編集する方法の詳細については、『Sun Java System Web Server 7.0 管理ガイド』を参照してください。

アドレス

Address フィールドには、この待機ソケットが待機する基底アドレスが含まれます。1 つのホストが複数のネットワークインタフェースと複数の IP アドレスを持つ可能性があります。アドレスには IP アドレスとポート番号が含まれます。

ホストマシンのすべてのネットワークインタフェース上で待機ソケットが待機する場合、アドレスの IP 部分は 0.0.0.0 になります。

チューニング

この設定は、HTTP リスナーの編集時にチューニング可能です。0.0.0.0 以外の IP アドレスを指定すると、サーバーが接続ごとに行うシステムコールの数が、1 つだけ少なくなります。実現可能な最高のパフォーマンスが得られるよう、0.0.0.0 以外の IP アドレスを指定してください。

アクセプタスレッド

アクセプタスレッドは、接続を待機するスレッドです。それらのスレッドが接続を受け付けてキューに入れたあと、ワークスレッドがそれらの接続を取り出します。詳細については、「接続処理の概要」を参照してください。

ユーザーからの要求があったときにいつでも対応できるように、常に十分な数のアクセプタスレッドを用意しておくのが理想的ですが、システムに負荷がかかり過ぎない数に抑える必要もあります。推奨の規則は、システム上の CPU ごとにアクセプタスレッドを 1 つずつ用意することです。TCP/IP 待機キューのオーバーランが発生する場合には、この値を CPU 数の約 2 倍に増やすことができます。

チューニング

この設定は、HTTP リスナーの編集時にチューニング可能です。デフォルトは 1 です。

パフォーマンスに影響を与えるその他の HTTP リスナー設定は、送信バッファーと受信バッファーのサイズです。これらのバッファーの詳細については、使用しているオペレーティングシステムのマニュアルを参照してください。

デフォルト仮想サーバー

仮想サーバーは、HTTP 1.1 の Host ヘッダーを使って動作します。エンドユーザーのブラウザが Host ヘッダーを送信しなかった場合や、サーバーが Host ヘッダーに指定された仮想サーバーを見つけられなかった場合、Web Server はデフォルト仮想サーバーを使って要求を処理します。エラーメッセージを送信したり、特殊なドキュメントルートからのページを提供したりするように、デフォルト仮想サーバーを構成することができます。

チューニング

この設定は、HTTP リスナーの編集時にチューニング可能です。

キープアライブ情報

このセクションでは、サーバーの HTTP レベルキープアライブシステムに関する情報が提供されます。

注 –

「キープアライブ (keep alive)」という名前を TCP の keep-alives と混同しないようにしてください。また、HTTP 1.1 では「キープアライブ」という名前が PersistentConnections に変更されましたが、Web Server では引き続き、それらの接続をキープアライブ接続と呼んでいます。

次の例は、perfdump で表示されるキープアライブ統計を示したものです。

KeepAliveInfo:
--------------------
KeepAliveCount        198/200
KeepAliveHits         0
KeepAliveFlushes      0
KeepAliveRefusals     56844280
KeepAliveTimeouts     365589
KeepAliveTimeout      10 seconds

次の表に、管理コンソールで表示されるキープアライブ統計を示します。

表 2–3 キープアライブ統計情報

処理した接続の数 

0 

追加した接続の合計数 

198 

最大接続サイズ 

200 

フラッシュした接続の数 

0 

拒否された接続の数 

56844280 

終了したアイドル接続の数 

365589 

接続タイムアウト 

10 

HTTP 1.0 と HTTP 1.1 はどちらも、単一の HTTP セッションで複数の要求を送信する機能をサポートしています。Web サーバーは、新しい HTTP 要求を 1 秒間に数百件受信できます。すべての要求の接続をいつまでも開いたままにできると、サーバーは多くの接続で過負荷状態になってしまう可能性があります。UNIX および Linux システム上では、これにより、ほんのわずかな負荷でファイルテーブルのオーバーフローが発生する可能性があります。

この問題に対処するため、サーバーは、待機キープアライブ接続の最大数のカウンタを維持します。待機キープアライブ接続は、以前の要求の処理を完了し、その同じ接続上で新しい要求が到着するのを待っています。サーバー上で最大待機接続数を超える接続が開いた状態で、新しい接続がキープアライブ要求を待機している場合、サーバーはもっとも古い接続を閉じます。このアルゴリズムにより、サーバーが維持できる開いた待機キープアライブ接続の上限が保たれます。

Sun Java System Web Server は必ずしも、クライアントからのキープアライブ要求に従うとは限りません。次の条件が成立する場合には、クライアントがキープアライブ接続を要求しても、サーバーは接続を閉じます。

Web Server のキープアライブサブシステムは、きわめて高いスケーラビリティーを実現できるように設計されています。デフォルトの構成は、作業負荷が持続的でない場合 (つまり、KeepAlive ヘッダーを持たない HTTP 1.0 の場合) や、主にキープアライブ接続へのサービスを提供する低負荷システムで使用する場合には、最適でない可能性があります。

キープアライブカウント

perfdump のこのセクションには、次の 2 つの数値が含まれます。

チューニング

サーバーがもっとも古い接続を閉じる前に待機を同時に許可する接続の最大数を管理コンソールでチューニングするには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「最大接続数」フィールドを編集します。デフォルトは 200 です。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで max-connections プロパティーを使用します。

注 –

最大接続数の設定に指定された接続数は、キープアライブスレッド間で均等に分割されます。最大接続数の設定がキープアライブスレッド数の設定で均等に分割できない場合、サーバーは、同時キープアライブ接続の最大数よりも若干多い値を許可する可能性があります。

キープアライブヒット数

キープアライブヒット数 (処理された接続の数) は、キープアライブ接続から要求が正常に受信された回数です。

この設定はチューニング不可能です。

キープアライブフラッシュ数

追加された接続の合計数がキープアライブ最大接続数の設定を超えたために、サーバーが接続を閉じなければいけなかった回数。このサーバーは、キープアライブ数が最大接続サイズを超えても既存の接続を閉じません。代わりに、新しいキープアライブ接続が拒否され、拒否された接続の数が増分されます。

キープアライブ拒否数

おそらく持続的接続が多すぎたために (あるいは追加された接続の合計数がキープアライブ最大接続数の設定を超えたときに)、サーバーが接続をキープアライブスレッドに渡せなかった回数。推奨のチューニングは、キープアライブ最大接続数を増やすことです。

キープアライブタイムアウト数

クライアント接続が何の活動も見られないままタイムアウトに達し、サーバーがそのアイドル状態のキープアライブ接続を閉じた回数。この統計は監視対象として有用ですが、推奨のチューニング方法は特にありません。

キープアライブタイムアウト

アイドル状態のキープアライブ接続が閉じられるまでの時間 (秒)。この値を管理コンソールで設定するには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「タイムアウト」フィールドを使用します。デフォルトは 30 秒ですが、これは、アイドル状態が 30 秒を超えると接続がタイムアウトすることを意味します。最大値は 3600 秒 (60 分) です。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで timeout プロパティーを使用します。

キープアライブポーリング間隔

キープアライブポーリング間隔は、システムがキープアライブ接続に対するポーリングを行なって要求の有無を確認する間隔 (秒) を指定します。デフォルトは、許可される最小値である 0.001 秒です。これが小さな値に設定されているのは、CPU の使用率を犠牲にしてパフォーマンスを向上させるためです。

ポーリング間隔をチューニングするには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「ポーリング間隔」フィールドを編集します。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで poll-interval プロパティーを使用します。

キープアライブスレッド数

キープアライブシステムで使用されるスレッドの数を管理コンソールで構成するには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「キープアライブ設定」の下にある「スレッド数」フィールドを編集します。デフォルトは 1 です。コマンド行インタフェースでは、wadm set-keep-alive-prop コマンドで threads プロパティーを使用します。

HTTP 1.0 スタイルの作業負荷に対するチューニング

HTTP 1.0 では新しい受信接続が多数発生するため、1 待機ソケットあたりのアクセプタスレッド数のデフォルト値 1 は、最適であるとは言えません。HTTP 1.0 スタイルの作業負荷では、これを大きな数値に増やすとパフォーマンスが改善されるはずです。たとえば、2 個の CPU を備えたシステムの場合、これを 2 に設定することをお勧めします。また、キープアライブ接続数を 0 などに減らすこともお勧めします。

HTTP 1.0 スタイルの作業負荷では、多数の接続が確立され、終了されます。

サーバーが高負荷状態のときにブラウザから Web Server への接続でタイムアウトが発生する場合には、HTTP リスナーの待機キューサイズを 8192 などの大きな値に設定することで、HTTP リスナーのバックログキューのサイズを増やすことができます。

HTTP リスナーの待機キューは、ある待機ソケット上で保留される接続の最大数を指定します。バックログキューがいっぱいになった待機ソケット上で接続がタイムアウトすると、その接続は失敗します。

HTTP 1.1 スタイルの作業負荷に対するチューニング

一般に、サーバーによる持続的接続の処理をチューニングする場合、スループットと待ち時間はトレードオフの関係になります。キープアライブポーリング間隔とタイムアウトによって待ち時間が決まります。これらの設定の値を小さくすることの狙いは、ページの読み込み時間を短縮するなど、低負荷システムでの待ち時間を短縮することです。これらの設定の値を増やすことの狙いは、サーバーが 1 秒間に処理できる要求の数を増やすなど、高負荷システムでの全体的なスループットを高めることです。ただし、待ち時間が長すぎるのにクライアントが少なすぎる場合には、サーバーが不必要にアイドル状態になるため、全体的なスループットが低下します。結論として、ある特定の負荷状態におけるキープアライブサブシステムの一般的なチューニング規則は、次のようになります。

また、チャンクエンコーディングは、HTTP 1.1 の作業負荷でのパフォーマンスに影響を与える可能性があります。応答バッファーサイズのチューニングは、パフォーマンスに良い影響を与える可能性があります。構成の「パフォーマンス」タブ ⇒ 「HTTP」タブで応答バッファーサイズを大きくすると、応答がチャンクに分割される代わりに、Content-length: ヘッダーが送信されるようになります。CLI を使ってバッファーサイズを設定するには、wadm set-http-prop コマンドの output-buffer-size プロパティーを使用します。

また、obj.conf ファイル内で Service クラスの関数のバッファーサイズを UseOutputStreamSize パラメータを使って設定することもできます。UseOutputStreamSize は、output-buffer-size プロパティーを使って設定された値よりも優先されます。UseOutputStreamSize が設定されていない場合、Web Server は output-buffer-size の設定を使用します。output-buffer-size が設定されていない場合、Web Server は output-buffer-size のデフォルト値 8192 を使用します。

次の例は、CLI を使って出力バッファーサイズを増やしたあと、構成を配備する方法を示したものです (obj.conf で UseOutputStreamSize が指定されていない場合に使用される)。 

./wadm set-http-prop --user=admin-user --password-file=admin-password-file 
--config=config-name output-buffer-size=16384
./wadm deploy-config --user=admin-user --password-file=admin-password-file
 --config=config-name

次の例は、nsapi_test Service 関数のバッファーサイズを設定する方法を示したものです。

<Object name="nsapitest">
 ObjectType fn="force-type" type="magnus-internal/nsapitest"
 Service method=(GET) type="magnus-internal/nsapitest" fn="nsapi_test"
 UseOutputStreamSize=12288
</Object>

セッション作成 (スレッド) 情報

セッション (スレッド) 作成の統計は、perfdump では次のように表示されます。

SessionCreationInfo:
------------------------
Active Sessions           128
Keep-Alive Sessions       0
Total Sessions Created    128/128

Active Sessions は、現在要求を処理しているセッションの数 (要求処理のスレッド) を示しています。

Keep-Alive Sessions には、キープアライブセッションを処理する HTTP 要求処理スレッドの数が表示されます。

perfdump の Total Sessions Created には、作成されたセッションの数と最大スレッド数が表示されます。

管理コンソールでこれに相当する情報である「スレッドの合計数」は、「監視」タブ ⇒「インスタンス」サブタブの「一般統計」の下で利用可能になっています。許容される最大のスレッド数を表示するには、構成の「パフォーマンス」タブ ⇒「HTTP」サブタブの、「スレッドプール設定」の下にある「最大スレッド数」フィールドを参照してください。

perfdump の Active Sessions に相当する情報を得るには、「スレッドの合計数」から「アイドルスレッドの数」を引きます。

最大スレッド数 (最大同時要求数)

最大スレッド数の設定は、Web Server が処理できる同時トランザクションの最大数を指定します。デフォルト値は 128 です。この値を変更するとサーバーのパフォーマンスを調整でき、実行されるトランザクションの待ち時間を最小限に抑えることができます。「最大スレッド数」の値は複数の仮想サーバーにまたがって適用されますが、その際に負荷分散が試みられることはありません。これは構成ごとに設定されます。

設定されたスレッドの最大数に達してしまってもかまいません。また、サーバーのスレッド数を反射的に増やす必要もありません。この最大限度に達したということは、サーバーがピークロード時にこれだけの数のスレッドを必要としたことを意味しています。しかし、要求がタイムリーに処理されているかぎり、サーバーは適切にチューニングされているといえます。ただし、この時点で接続は接続キューに入れられるため、オーバーフローする可能性もあります。サーバーのパフォーマンスを定期的に監視し、作成されたセッションの合計数が最大スレッド数に近くなることが多いようであれば、スレッドの上限を増やすことを検討するべきです。

同時処理する要求数を計算するために、サーバーはアクティブな要求数をカウントし、そこに新しい要求が届いたら 1 を足し、要求が終了したら 1 を引きます。新しい要求が到着すると、サーバーは処理中の要求がすでに最大数に達しているかどうかをチェックします。上限に達していた場合、サーバーは、アクティブな要求の数がその最大量を下回るまで、新しい要求の処理を遅らせます。

理論上は、最大スレッド数を 1 に設定しても、サーバーは正常に機能します。この値を 1 に設定することは、サーバーが一度に処理できる要求が 1 つだけであることを意味しますが、静的ファイルの HTTP 要求の処理時間は一般に非常に短い (応答時間はわずか 5 ミリ秒程度である可能性がある) ため、一度に 1 つの要求を処理したとしても、1 秒間に最大 200 件の要求を処理できることになります。

ただし、実際には、インターネットクライアントがサーバーに接続したあと、要求を完了しないことが頻繁に発生します。そうした場合には、サーバーはデータの到着を 30 秒またはそれ以上待ったあと、タイムアウトを発生させます。このタイムアウト時間を定義するには、構成の「パフォーマンス」タブ ⇒「HTTP 設定」ページの「入出力タイムアウト」設定を使用します。また、コマンド wadm set-http-prop を使って io-timeout プロパティーを設定することもできます。デフォルトは 30 秒です。これをデフォルトより小さい値に設定すれば、スレッドがより早く解放されるようになりますが、一方で低速な接続のユーザーを切断する可能性も出てきます。また、一部のサイトでは、完了までに数分かかる高負荷のトランザクションが実行されます。これらの要因はどちらも、必要とされる最大同時要求数を増加させます。多くの秒数のかかる要求を多数処理するサイトでは、最大同時要求数を増やさなければいけない可能性があります。

適切な最大スレッド値の範囲は、負荷によって 100 〜 500 になります。「最大スレッド数」は同時に実行可能なアクティブスレッドの最大数に対する強い制限値を表しますが、これがパフォーマンス上の障害になる可能性があります。デフォルト値は 128 です。

スレッドプールの最小スレッド数は、サーバーが起動時に開始するスレッドの最小数です。デフォルト値は 16 です。

注 –

SNCA (Solaris Network Cache and Accelerator) と組み合わせて使用するように Web Server を構成する場合、最大スレッド数とキューサイズを 0 に設定するとパフォーマンスが改善されます。SNCA がクライアント接続を管理するので、これらのパラメータを設定する必要はありません。SNCA を使用しない構成でも、これらのパラメータを 0 に設定できます。キープアライブを使用しないで待ち時間の短い応答を配信する必要がある場合は特にそうです。最大スレッド数とキューサイズの「両方」を 0 に設定する必要があることに注意してください。

SNCA の使用方法については、「Solaris Network Cache and Accelerator (SNCA) の使用」を参照してください。

チューニング

管理コンソールでスレッドの上限を増やすには、構成の「パフォーマンス」タブ ⇒「HTTP」タブの、「スレッドプール設定」の下にある「最大スレッド数」フィールドを編集します。コマンド行インタフェースでは、wadm set-thread-pool-prop コマンドの max-threads プロパティーを使用します。デフォルトは 128 です。

ファイルキャッシュ情報 (静的コンテンツ)

キャッシュ情報セクションは、ファイルキャッシュがどのように使用されているかに関する統計を提供します。ファイルキャッシュには静的コンテンツが書き込まれるため、サーバーは静的コンテンツに対する要求をすばやく処理できます。ファイルキャッシュには、ファイルに関する情報と静的なファイルコンテンツが保存されます。ファイルキャッシュでは、サーバーにより解析される HTML の処理の高速化に使用される情報もキャッシュに書き込まれます。サーブレットや JSP では、別の種類のキャッシュが使用されます。

コンテンツへの更新がスケジュールに従って行われるサイトでは、コンテンツの更新中はキャッシュを停止し、更新完了後にキャッシュを再度起動することを検討してください。キャッシュを無効にすると、パフォーマンスは低下しますが、サーバーは正常に動作します。

パフォーマンス上の理由により、Web Server はキャッシュへの書き込みを次のように行います。

次に、perfdump でのキャッシュ統計の表示例を示します。

CacheInfo:
------------------
enabled             yes
CacheEntries        12/1024
Hit Ratio           46/98 ( 46.94%)
Maximum Age         30

次の表に、管理コンソールで表示されるファイルキャッシュ統計を示します。

表 2–4 ファイルキャッシュ統計

キャッシュヒットの合計 

46 

キャッシュミスの合計 

52 

キャッシュコンテンツヒットの合計 

0 

ファイル検索エラーの数 

9 

ファイル情報検索の数 

37 

ファイル情報検索エラーの数 

50 

エントリ数 

12 

最大キャッシュサイズ 

1024 

オープンファイルエントリの数 

0 

許可されている最大オープンファイル数 

1024 

ヒープサイズ (Heap Size) 

36064 

最大ヒープキャッシュサイズ 

10735636 

メモリーマップファイルコンテンツのサイズ 

0 

最大メモリーマップファイルサイズ 

0 

エントリの最大継続時間 

30 

有効

キャッシュが無効になっていると、このセクションの残りの部分が perdump で表示されません。管理コンソールでは、「ファイルキャッシュ統計」セクションの値としてゼロが表示されます。

チューニング

キャッシュはデフォルトで有効になっています。管理コンソールでこれを無効にするには、構成の「パフォーマンス」タブ ⇒「キャッシュ」サブタブの「ファイルキャッシュ」の下にある、「ファイルキャッシュ」の「有効」ボックスの選択を解除します。コマンド行インタフェースでこれを無効にするには、wadm set-file-cache-prop を使って enabled プロパティーを false に設定します。

キャッシュエントリ数

キャッシュエントリの現在の数と最大数の両方が、perfdump に表示されます。管理コンソールでは、それらは「エントリ数」および「最大キャッシュサイズ」と呼ばれます。単一のキャッシュエントリは単一の URI を表します。

チューニング

管理コンソールでキャッシュエントリの最大数を設定するには、構成の「パフォーマンス」タブ ⇒「キャッシュ」タブの、「ファイルキャッシュ」の下にある「最大エントリ数」フィールドを使用します。コマンド行インタフェースでは、wadm set-file-cache-prop を使って max-entries プロパティーを設定します。デフォルトは 1024 です。値の範囲は 1 〜 1048576 です。

ヒット率 (キャッシュヒット数 / キャッシュ検索数)

perfdump 経由で利用可能なヒット率は、キャッシュ検索数に対するファイルキャッシュヒット数です。100% に近い数値が、ファイルキャッシュが効果的に機能していることを示しているのに対し、0% に近い数値は、ファイルキャッシュがあまり多くの要求を処理できていないことを示している可能性があります。

管理コンソール経由で提供される統計に基づいてこの数値を手動で計算するには、「キャッシュヒットの合計」と「キャッシュミスの合計」を足したもので、「キャッシュヒットの合計」を割ります。

この設定はチューニング不可能です。

最大継続時間

このフィールドには、有効なキャッシュエントリの最大継続時間が表示されます。このパラメータは、ファイルがキャッシュに書き込まれたあと、そのキャッシュ情報がどのくらいの期間使用されるかを制御します。最大継続時間を経過したエントリは、同じファイルの新しいエントリで置き換えられます。

チューニング

コンテンツを定期的に更新 (既存のファイルを変更) するかどうかに基づいて最大時間を設定します。たとえば、コンテンツが定期的に 1 日に 4 回更新される場合、最大時間を 21600 秒 (6 時間) に設定できます。それ以外の場合、最大時間には、ファイルが変更されたあと、以前のバージョンのコンテンツファイルを提供する最大時間を設定することを検討してください。コンテンツの変更頻度が低い Web サイトでは、パフォーマンスを改善するためにこの値を増やすことをお勧めします。

管理コンソールで最大継続時間を設定するには、構成の「パフォーマンス」タブ ⇒「キャッシュ」タブの、「ファイルキャッシュ」の下にある「最大継続時間」フィールドを使用します。コマンド行インタフェースでは、wadm set-file-cache-prop を使って max-age プロパティーを変更します。デフォルトは 30 秒です。値の範囲は 0.001 〜 3600 です。

最大ヒープキャッシュサイズ

最適なキャッシュヒープサイズは、システムメモリーの空き容量がどのくらい存在するかによって異なります。ヒープサイズを大きくすれば、Web Server がより多くのコンテンツをキャッシュに書き込めるため、ヒット率も向上することになります。ただし、オペレーティングシステムがキャッシュに書き込まれたファイルのページングを開始するほどヒープサイズを大きくすべきではありません。

チューニング

管理コンソールで最大ヒープサイズを設定するには、構成の「パフォーマンス」タブ ⇒「キャッシュ」タブの、「ファイルキャッシュ」の下にある「最大ヒープスペースサイズ」フィールドを使用します。コマンド行インタフェースでは、wadm set-file-cache-prop を使って max-heap-space プロパティーを変更します。デフォルト値は 10485760 バイトです。値の範囲は 0 〜 9223372036854775807 です。32 ビット Web Server では、プロセスはファイルキャッシュ用に 4G バイトのアドレス空間を使用するため、この値は 4G バイト未満にするべきです。

nocache パラメータの使用

Service 関数send-file でパラメータ nocache を使えば、ある特定のディレクトリ内のファイルをキャッシュに書き込まないように指定できます。この変更を行うには obj.conf を編集します。たとえば、変更頻度が高すぎるためにキャッシュに書き込んでもあまり役に立たないような一連のファイルが存在する場合、それらのファイルをあるディレクトリに格納し、obj.conf を編集してそのディレクトリ内のファイルをキャッシュに書き込まないようにサーバーに指示することができます。

例

<Object name=default>
...
NameTrans fn="pfx2dir" from="/myurl" dir="/export/mydir"
name="myname"
...
Service method=(GET|HEAD|POST) type=*~magnus-internal/*
fn=send-file
...
</Object>
<Object name="myname">
Service method=(GET|HEAD) type=*~magnus-internal/* fn=send-file
nocache=""
</Object>

この例では、URL プレフィックス /myurl によって /export/mydir/ 内の静的ファイルが要求された際に、サーバーはそれらのファイルをキャッシュに書き込みません。obj.conf の編集方法の詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference 』を参照してください。

ファイルキャッシュの動的な制御と監視

obj.conf にオブジェクトを追加すれば、サーバーの実行中にファイルキャッシュを動的に監視および制御できます。

Procedureファイルキャッシュを制御および監視する

  1. NameTrans 指令をデフォルトオブジェクトに追加します。

    NameTrans fn="assign-name" from="/nsfc" name="nsfc"

  2. nsfc オブジェクトの定義を追加します。

    <Object name="nsfc">
Service fn="service-nsfc-dump"
</Object>

    これにより、ファイルキャッシュを制御および監視するための関数 (nsfc-dump) に、URI /nfsc 経由でアクセスできるようになります。別の URI を使用するには、NameTrans 指令の from パラメータを変更します。

    次に、この URI へのアクセス時に表示される情報の例を示します。


    Sun Java System File Cache Status (pid 3602)

The file cache is enabled.
Cache resource utilization

Number of cached file entries = 174968 (152 bytes each, 26595136 total bytes)
Heap space used for cache = 1882632616/1882632760 bytes
Mapped memory used for medium file contents = 0/1 bytes
Number of cache lookup hits = 47615653/48089040 ( 99.02 %)
Number of hits/misses on cached file info = 23720344/324195
Number of hits/misses on cached file content = 16247503/174985
Number of outdated cache entries deleted = 0
Number of cache entry replacements = 0
Total number of cache entries deleted = 0

Parameter settings

ReplaceFiles: false
ReplaceInterval: 1 milliseconds
HitOrder: false
CacheFileContent: true
TransmitFile: false
MaxAge: 3600 seconds
MaxFiles: 600000 files
SmallFileSizeLimit: 500000 bytes
MediumFileSizeLimit: 1000001 bytes
BufferSize: 8192 bytes

CopyFiles: false
Directory for temporary files: /tmp
Hash table size: 1200007 buckets

    この URI へのアクセス時には、クエリー文字列を含めることができます。次の値が認識されます。

    • ?list: キャッシュ内のファイルを一覧表示する。

    • ?refresh=n: n 秒ごとにクライアントがページの再読み込みを行うようにする。

    • ?restart: キャッシュが停止後、再起動されるようにする。

    • ?start: キャッシュを起動する。

    • ?stop: キャッシュをシャットダウンする。

    ?list オプションを選択する場合、そのファイルリストには、ファイル名、一連のフラグ、現在のキャッシュエントリ参照数、ファイルのサイズ、および内部ファイル ID 値が含まれます。フラグは次のとおりです。

    • C: ファイルのコンテンツがキャッシュに書き込まれている。

    • D: キャッシュエントリが削除対象としてマークされている。

    • E: PR_GetFileInfo() がこのファイルでエラーを返した。

    • I: ファイルの情報 (サイズや変更日付など) がキャッシュに書き込まれている。

    • M: ファイルのコンテンツが仮想メモリー内にマップされている。

    • O: ファイル記述子がキャッシュに書き込まれている (TransmitFile が true に設定されている場合)。

    • P: ファイルに非公開データが関連付けられている (shtml ファイルの場合に表示されるはず)。

    • T: キャッシュエントリが一時ファイルを持っている。

    • W: キャッシュエントリが書き込みアクセス用としてロックされている。

スレッドプール情報

ユーザーがデフォルト設定を使用している場合、デフォルトスレッドプール内のスレッドが要求を処理します。ただし、カスタムスレッドプールを作成し、それらを使ってカスタム NSAPI 関数を実行することもできます。Web Server はデフォルトで、NativePool という名前の追加プールを 1 つ作成します。ほとんどの場合、ネイティブスレッドプールが必要になるのは、Windows プラットフォームの場合だけです。スレッドプールの詳細については、「スレッド、プロセス、および接続の理解」を参照してください。

ネイティブスレッドプール

次の例は、perfdump で表示されるネイティブスレッドプール情報を示したものです。

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0
my-custom-pool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0

ユーザーが追加のカスタムスレッドプールを定義した場合、それらのプールは perfdumpの「Native Pools」見出しの下に表示されます。

次の表に、管理コンソールで表示されるスレッドプール統計を示します。ユーザーが追加のスレッドプールを定義しなかった場合は、NativePool のみが表示されます。

表 2–5 スレッドプールの統計

名前 

NativePool 

アイドル状態のスレッド 

1 

スレッド数 

1 

待機した要求 

0 

待機した最大要求数 

0 

アイドル/ピーク/制限

Idle は管理コンソールでは「アイドル状態のスレッド」として表示されますが、これは、現在アイドル状態になっているスレッドの数を示します。Peak は、プール内のピークスレッド数を示します。Limit は管理コンソールでは「スレッド数」として表示されますが、これは、スレッドプール内で許可されるネイティブスレッドの最大数を示しており、NativePool の場合は、magnus.conf ファイル内の NativePoolMaxThreads の設定によって決まります。

チューニング

NativePool の最大スレッド数を変更するには、magnus.conf 内の NativePoolMaxThreads パラメータを編集します。詳細については、「NativePoolMaxThreads 指令」を参照してください。

ワークキューの長さ/ピーク/制限

これらの数値は、プール内のネイティブスレッドを使用するために待機しているサーバー要求のキューに関するものです。Work Queue Length はネイティブスレッドを待機している要求の現在の数であり、管理コンソールでは「待機した要求」として表示されます。

Peak (管理コンソールでは「待機した最大要求数」) は、ネイティブスレッドを使用するためにキュー内に同時に存在していた要求の、サーバーが起動されてからその時点までの最大数です。この値は、ネイティブスレッドを必要とする要求の最大並行性とみなすことができます。

Limit はネイティブスレッドを待機するためにキュー内に一度に格納できる要求の最大数であり、NativePoolQueueSize の設定によって決まります。

チューニング

NativePool のキューサイズを変更するには、magnus.conf 内の NativePoolQueueSize 指令を編集します。詳細については、「NativePoolQueueSize 指令」を参照してください。

NativePoolStackSize 指令

NativePoolStackSize は、ネイティブ (カーネル) スレッドプール内の各スレッドのスタックサイズをバイト単位で決定します。

チューニング

NativePoolStackSize を変更するには、magnus.conf 内の NativePoolStackSize 指令を編集します。

NativePoolQueueSize 指令

NativePoolQueueSize は、スレッドプール用のキュー内で待機できるスレッドの数を決定します。プール内のすべてのスレッドがビジー状態になると、ネイティブプール内のスレッドを使用する必要のある次の要求処理スレッドは、キュー内で待機する必要があります。キューがいっぱいになると、次の要求処理スレッドがキューに入ろうとしても拒否され、最終的にそのスレッドはクライアントにビジー応答を返します。その後、そのスレッドは、キュー内で待機しながら拘束される代わりに、別の受信要求を自由に処理できるようになります。

NativePoolQueueSize を最大スレッド数の値よりも小さい値に設定すると、プールスレッドによるサービスを待機している要求の数がこの値を超えるたびに、サーバーは目的とする NSAPI 関数の代わりにビジー関数を実行します。デフォルトでは、「503 Service Unavailable」応答が返され、ログレベルの設定に応じたメッセージがログに記録されます。NativePoolQueueSize を最大スレッド数よりも大きい値に設定すると、ビジー関数が実行可能になる前にサーバーが接続を拒否します。

この値は、ネイティブスレッドを必要とするサービスを同時に求める要求の最大数を表します。負荷が高いためにシステムが要求を処理できない場合に、待機可能な要求の数を増やすと、要求の待ち時間が長くなり、利用可能なすべての要求スレッドが 1 つのネイティブスレッドを待機することになる可能性があります。一般に、この値は、ネイティブスレッドを必要とする要求を実行する同時ユーザーの最大数を予想し、その要求が拒否されるのを回避できるだけの大きな値に設定します。

この値と最大スレッド数の違いは、静的 HTML や画像ファイルなどの、非ネイティブスレッド要求のために予約される要求数にあります。予約を確保して要求を拒否することで、サーバーが静的ファイルの要求を処理し続けることを保証でき、動的コンテンツの高負荷時にサーバーが応答不能になるのを防ぐことができます。サーバーが常に接続を拒否する場合には、この値の設定が小さすぎるか、あるいはサーバーのハードウェアが過負荷状態になっています。

チューニング

NativePoolQueueSize を変更するには、magnus.conf 内の NativePoolQueueSize 指令を編集します。

NativePoolMaxThreads 指令

NativePoolMaxThreads は、ネイティブ (カーネル) スレッドプール内のスレッドの最大数を決定します。

値を大きくするほど、同時に実行可能な要求が多くなりますが、コンテキストの切り替えによるオーバーヘッドも大きくなります。したがって、値が大きいほど良いとは限りません。通常の場合、この数値を増やす必要はありませんが、CPU がまだ飽和状態に達しておらず、かつ待機中の要求が多数存在している場合には、この数値を増やすべきです。

チューニング

NativePoolMaxThreads を変更するには、magnus.conf 内の NativePoolMaxThreads パラメータを編集します。

NativePoolMinThreads 指令

ネイティブ (カーネル) スレッドプール内のスレッドの最小数を決定します。

チューニング

NativePoolMinThreads を変更するには、magnus.conf 内の NativePoolMinThreads パラメータを編集します。

DNS キャッシュ情報

DNS キャッシュでは、IP アドレスと DNS 名がキャッシュされます。Web Server は、DNS キャッシュを使ってロギングや IP アドレスによるアクセス制御を行います。DNS キャッシュはデフォルトで有効になっています。次の例は、perfdump で表示される DNS キャッシュ情報を示したものです。

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        4/1024
HitRatio            62854802/62862912 ( 99.99%)

AsyncDNS Data:
------------------
enabled             yes
NameLookups         0
AddrLookups         0
LookupsInProgress   0

次の例に、管理コンソールで表示される DNS キャッシュ情報を示します。

表 2–6 DNS キャッシュの統計

キャッシュヒットの合計 

62854802 

キャッシュミスの合計 

6110 

非同期検索の数 

0 

検索中 

4 

非同期検索が有効 

1 

実行した非同期アドレス検索の数 

0 

有効

DNS キャッシュが無効になっていると、このセクションの残りの部分が perfdump で表示されません。管理コンソールではページにゼロが表示されます。

チューニング

DNS キャッシュはデフォルトで有効になっています。管理コンソールで DNS キャッシュを有効または無効にするには、構成の「パフォーマンス」タブ ⇒「DNS」サブタブの、「DNS キャッシュ設定」の下で、「DNS キャッシュ」の「有効」ボックスを選択または選択解除します。コマンド行インタフェースでこれを有効または無効にするには、wadm set-dns-cache-prop を使って enabled プロパティーを設定します。

キャッシュエントリ数 (現在のキャッシュエントリ数/最大キャッシュエントリ数)

perfdump のこのセクションには、キャッシュエントリの現在の数と最大数が表示されます。管理コンソールでは、現在のキャッシュエントリ数は「キャッシュヒットの合計」として表示されます。単一のキャッシュエントリは、単一の IP アドレスまたは単一の DNS 名の検索を表します。キャッシュのサイズは、Web サイトに同時にアクセスするクライアントの最大数と同程度にするべきです。キャッシュサイズが大きすぎるとメモリーが浪費され、パフォーマンスも低下します。

チューニング

管理コンソールで DNS キャッシュの最大サイズを設定するには、構成の「パフォーマンス」タブ ⇒「DNS」サブタブの、「DNS キャッシュ設定」の下にある「最大キャッシュサイズ」フィールドを使用します。コマンド行インタフェースでこれを設定するには、wadm set-dns-cache-prop を使って max-entries プロパティーを設定します。デフォルトのキャッシュサイズは 1024 です。値の範囲は 2 〜 32768 です。

ヒット率 (キャッシュヒット数/キャッシュ検索数)

perfdump のヒット率には、キャッシュ検索数に対するキャッシュヒット数が表示されます。管理コンソールの統計に基づいてこの数値を計算するには、「キャッシュヒットの合計」と「キャッシュミスの合計」を足したもので、「キャッシュヒットの合計」を割ります。

この設定はチューニング不可能です。

非同期 DNS が有効/無効

Async DNS enabled/disabled には、サーバーがオペレーティングシステムの同期リゾルバの代わりに独自の非同期 DNS リゾルバを使用するかどうかが表示されます。非同期 DNS はデフォルトで無効になっています。これが無効になっていると、このセクションが perfdump で表示されません。管理コンソールでこれを有効にするには、構成の「パフォーマンス」タブ ⇒「DNS」タブの「DNS 検索設定」の下で、「非同期 DNS」を選択します。コマンド行インタフェースでこれを有効にするには、wadm set-dns-prop を使って async プロパティーを true に設定します。

Java 仮想マシン (JVM) 情報

JVM の統計が表示されるのは、管理コンソール、CLI、および stats-xml を使用する場合だけです。perfdump ではそれらは表示されません。

次の表に、管理コンソールで表示される JVM 統計の例を示します。

表 2–7 Java 仮想マシン (JVM) の統計

仮想マシン名 

Java HotSpotTM Server VM

仮想マシンベンダー 

Sun Microsystems Inc. 

仮想マシンのバージョン 

1.5.0_06-b05 

ヒープメモリーサイズ 

5884856 

ガベージコレクション経過時間 (ミリ秒) 

51 

読み込んだクラスの現在の数 

1795 

読み込んだクラスの合計数 

1795 

読み込み解除したクラスの合計数 

0 

発生したガベージコレクションの数 

3 

ライブスレッドの数 

8 

開始したスレッドの数 

9 

最大ライブスレッドカウント 

8 

これらの統計のほとんどは、チューニング不可能です。これらは、JVM の動作に関する情報を提供します。

JVM に関するチューニング情報のもう 1 つの情報源は、JVM を監視および管理するための管理インタフェースを提供するパッケージ java.lang.management です。このパッケージの詳細については、http://java.sun.com/j2se/1.5.0/docs/api/java/lang/management/package-summary.html を参照してください。

Java ヒープチューニング

Web Server での Web アプリケーションのパフォーマンスは、ほかのすべての Java プログラムの場合と同じく、JVM が実行するヒープ管理に依存します。一時停止の時間とスループットの間には、トレードオフの関係が成立します。手始めに、http://java.sun.com/docs/hotspot/index.html から入手可能な Java HotSpot 仮想マシンのパフォーマンスドキュメントを読んでみてください。

具体的な関連ドキュメントとしては、『Tuning Garbage Collection with the 5.0 Java Virtual Machine』 や『Ergonomics in the 5.0 Java Virtual Machine』 などが挙げられます。

JVM オプションを管理コンソールで指定するには、構成の「Java」タブ ⇒「JVM 設定」サブタブを使用します。CLI では、wadm コマンド set-jvm-prop および set-jvm-profiler-prop を使用します。

Web アプリケーション情報

Web アプリケーション統計が表示されるのは、管理コンソール、wadm get-config-stats コマンド、および stats-xml を使用する場合だけです。perfdump ではそれらは表示されません。

Procedure管理コンソールから Web アプリケーション統計にアクセスする

  1. 「共通操作」ページから「監視」タブを選択します。

  2. 構成の Web アプリケーション統計を表示するには、構成名をクリックします。インスタンスの Web アプリケーション統計を表示するには、「インスタンス」サブタブをクリックし、インスタンス名をクリックします。

  3. 「監視統計」ページで、「仮想サーバーの統計」をクリックします。

  4. 仮想サーバー名をクリックします。

  5. 「仮想サーバーの監視統計」ページで「Web アプリケーション」をクリックします。

  6. 統計を表示する Web アプリケーションを、「Web アプリケーション」プルダウンメニューから選択します。

Web アプリケーションの統計

次の表に、管理コンソールで表示される Web アプリケーション統計の例を示します。

表 2–8 Web アプリケーションの統計

読み込んだ JSP の数 

1 

再読み込みした JSP の数 

1 

提供されたセッションの合計数 

2 

アクティブなセッションの数 

2 

アクティブセッションの最大数 

2 

拒否されたセッションの数 

0 

期限切れセッションの数 

0 

期限切れセッションが有効であった平均時間 (秒) 

0 

期限切れセッションが有効であった最長時間 (秒) 

0 

チューニング方法の詳細については、「Java Web アプリケーションのパフォーマンスチューニング」を参照してください。また、『Sun Java System Web Server 7.0 Developer’s Guide to Java Web Applications』も参照してください。

JDBC リソース情報

JDBC リソースとは、データベースへの JDBC 接続の名前付きグループのことです。JDBC リソースは、接続プールの作成に使用されるプロパティーを定義します。各 JDBC リソースは、サーバー起動時に JDBC ドライバを使って物理データベースへの接続を確立します。接続のプールが作成されるのは、Web Server の起動後、そのプールに対して最初の接続要求が発行されたときです。

JDBC ベースのアプリケーションまたはリソースは、プールから接続を取り出し、その接続を使用し、その接続が不要になった時点でそれをクローズして接続プールに返します。2 つ以上の JDBC リソースが同じプール定義を指している場合、それらのリソースは実行時に同じ接続プールを使用します。

接続プールを使用すると、次の処理によってアプリケーションのパフォーマンスが改善されます。

JDBC リソースの作成および編集は、管理コンソールの、構成に対する「Java」タブ ⇒「リソース」サブタブを使って行えます。また、 wadm create-jdbc-resource および set-jdbc-resource-prop コマンドを使用することもできます。詳細については、『Sun Java System Web Server 7.0 管理ガイド』を参照してください。

注 –

Web Server の起動時に各定義済みプールがインスタンス化されます。ただし、プールへのアクセスがはじめて発生するまで、接続が作成されることはありません。プールに重い負荷をかける前に、プールを軽く使用しておくべきです。

JDBC リソースの統計が利用可能になるのは、管理コンソール、CLI、および stats.xml を使用する場合だけです。perfdump ではそれらは表示されません。一部の監視データは、管理コンソール経由では利用できず、CLI の wadm get-config-stats および stats.xml 出力経由でしか表示できません。

プールはオンデマンドで作成されます。つまり、プールははじめて使用される時点で作成されます。監視統計は、プールがはじめて使用されるまで表示されません。

管理コンソール経由で利用可能な JDBC リソース統計

次の表に、管理コンソール経由で表示される JDBC リソース統計の例を示します。

表 2–9 JDBC リソース統計

接続 

32 

未使用接続 

0 

リース接続 

32 

平均キュー時間 

1480.00 

待機接続 

40 

接続タイムアウト 

100 

管理コンソール経由で JDBC リソースの設定を変更するには、対応する構成で、「Java」タブ ⇒「リソース」サブタブを選択します。JDBC リソースを選択します。「JDBC リソースを編集」ページで設定が利用可能になります。コマンド行インタフェース経由で JDBC リソースを変更するには、wadm set-jdbc-resource-prop を使用します。

接続数

この数値は現在の JDBC 接続数を示しており、未使用接続数とビジー接続数の両方を含みます。

チューニング – この設定はチューニング不可能ですが、プールの最新のアクティビティーを知るための良い指標になります。接続数が最小接続数よりも常に大きい場合、その現在の JDBC 接続数に近い値になるように最小接続数を増やすことを検討してください。管理コンソール経由で JDBC リソースの最小接続数を変更するには、「JDBC リソースを編集」ページで「最小接続数」設定を編集します。コマンド行インタフェース経由で JDBC リソースの最小接続数を変更するには、wadm set-jdbc-resource-prop を使って min-connections プロパティーを変更します。

未使用接続数

この数値は、プール内の未使用接続の現在数を示します。最小プールサイズを超える未使用接続はすべて、アイドル状態が最大アイドルタイムアウトを超えると閉じられます。未使用接続数はチューニング不可能です。

リース接続数

この数値は、プール内の使用中接続の現在数を示します。

チューニング – リース接続数が最小接続数よりも常に小さい場合、JDBC リソースの最小接続数を減らすことを検討してください。リース接続数が最小接続数よりも常に大きい場合、最小接続数を増やすことを検討してください。リース接続数が JDBC リソースの最大接続数と常に等しくなる場合、最大接続数を増やすことを検討してください。リース接続数の上限は最大接続数になります。

管理コンソール経由で JDBC リソースの最小接続数または最大接続数を変更するには、「JDBC リソースを編集」ページで「最小接続数」または「最大接続数」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースの最小接続数または最大接続数を変更するには、wadm set-jdbc-resource-prop を使って min-connections または max-connections プロパティーを変更します。

待機接続数

この数値は、JDBC プールから接続を受け取るために待機している接続要求の現在数を示します。現在のリース接続数が最大接続数に達すると、接続要求がキューに入れられます。

チューニング – この数値がゼロより常に大きい場合、JDBC リソースの最大接続数を増やすことを検討してください。管理コンソール経由で JDBC リソースの最大接続数を変更するには、「JDBC リソースを編集」ページで「最大接続数」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースの最大接続数を変更するには、wadm set-jdbc-resource-prop を使って max-connections プロパティーを変更します。

管理コンソールで利用不可能な JDBC リソース統計

一部の JDBC 統計は、wadm get-config-stats コマンド (--node オプションを使用)、stats-xml、および SNMP 経由では利用可能ですが、管理コンソール経由では利用不可能です。

maxConnections – 構成されたプールの最大サイズ。ほかの統計の基準値として使用してください。管理コンソール経由で JDBC リソースの最大接続数を変更するには、「JDBC リソースを編集」ページで「最大接続数」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースの最大接続数を変更するには、wadm set-jdbc-resource-prop を使って max-connections プロパティーを変更します。

peakConnections – プールの履歴に含まれている、同時にリースされた接続の数のうちで、最大のもの。この数値は、プール使用時の上限を知るための良い指標になります。これは、最大接続数の設定によって制限されます。

countTotalLeasedConnections – プールによって接続が提供された回数の合計。プールの総合的なアクティビティーを示します。チューニング不可能です。

countTotalFailedValidationConnections – 接続の検証が有効になっている場合、プールによって接続が無効であると判定された回数を示します。この数値が比較的大きい場合、それは、データベースやネットワークで問題が発生していることを意味している可能性があります。チューニング不可能です。

peakQueued – プールの寿命内の任意の時点で同時にキューに入っていた接続要求の数のうちで、最大のもの。チューニング不可能です。

millisecondsPeakWait – 任意の接続要求が待機キュー内に存在していたミリ秒単位の時間のうちで、最長のもの。この数値が大きい場合、それは、プールのアクティビティーが活発であることを示しています。上限は、JDBC リソース設定の待機タイムアウトになります。

countConnectionIdleTimeouts – 構成された JDBC アイドルタイムアウトを超過したためにプールによって閉じられた未使用接続の数。管理コンソール経由で JDBC リソースのアイドルタイムアウトを変更するには、「JDBC リソースを編集」ページで「アイドルタイムアウト」フィールドを編集します。コマンド行インタフェース経由で JDBC リソースのアイドルタイムアウトを変更するには、wadm set-jdbc-resource-prop を使って idle-timeout プロパティーを変更します。

JDBC リソースの接続設定

アプリケーションのデータベースアクティビティーによっては、JDBC リソースの接続プール設定のサイズを変更しなければいけない可能性があります。パフォーマンスに影響を与える JDBC リソースの属性のリストと、その値を設定する際のパフォーマンス上の考慮点を、次に示します。