この節では、管理コンソール、perfdump、コマンド行インタフェース、および stats-xml 経由で利用可能なパフォーマンス情報について説明します。ここでは、その情報を解析して一部のパラメータをチューニングすることで、サーバーのパフォーマンスを改善する方法について説明します。
デフォルトのチューニングパラメータはほとんどすべてのサイトに適していますが、扱うボリュームが非常に大きいサイトだけは例外です。大規模サイトでおそらく定期的に変更する必要のある設定は、スレッドプールとキープアライブの設定だけです。これらの設定を構成レベルでチューニングするには、管理コンソール、wadm コマンドのいずれかを使用します。server.xml ファイル内の要素を直接編集することでサーバーをチューニングすることも可能ですが、server.xml ファイルを直接編集すると作業が煩雑になる可能性があります。
perfdump は次のカテゴリの統計を監視しますが、これらの各カテゴリについては次の各節で説明します。ほとんどの場合、これらの統計は管理コンソール、コマンド行インタフェース、および stats-xml 出力にも表示されます。次の各節には、どの方法を使ってデータを監視するかにかかわらず、これらすべてのカテゴリのチューニング情報が含まれています。
これに加え、管理コンソール、コマンド行インタフェース、および stats-xml 経由で表示される統計情報には、perfdump の出力に含まれない別のカテゴリも含まれています。それらの統計をチューニングする方法については、次の各節で説明します。
必要な統計を表示し終わったら、管理コンソールの「パフォーマンス」タブを使用することで、サーバーのパフォーマンスに関するさまざまな側面を構成レベルでチューニングできます。管理コンソールの「パフォーマンス」タブには、次のような多数のパフォーマンスカテゴリの設定が含まれています。
HTTP 設定 (スレッドプールやキープアライブを含む)
DNS 設定
SSL および TLS の設定
キャッシュ設定
CGI 設定
アクセスログバッファー設定
また、適切な 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 リスナー情報には、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 は必ずしも、クライアントからのキープアライブ要求に従うとは限りません。次の条件が成立する場合には、クライアントがキープアライブ接続を要求しても、サーバーは接続を閉じます。
CGI などの動的コンテンツで HTTP content-length ヘッダーが設定されていない。このことは HTTP 1.0 要求だけに当てはまります。要求が HTTP 1.1 の場合には、content-length が設定されていなくても、サーバーはキープアライブ要求に従います。クライアントがチャンクエンコーディング (要求ヘッダー transfer-encoding: chunked で示される) を処理できる場合、サーバーはそれらの要求に対してこのエンコーディングを使用できます。
要求が HTTP GET、HEAD のいずれでもない。
要求が不正であると判定された。たとえば、クライアントがコンテンツを送信せず、ヘッダーのみを送信する場合などです。
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 では新しい受信接続が多数発生するため、1 待機ソケットあたりのアクセプタスレッド数のデフォルト値 1 は、最適であるとは言えません。HTTP 1.0 スタイルの作業負荷では、これを大きな数値に増やすとパフォーマンスが改善されるはずです。たとえば、2 個の CPU を備えたシステムの場合、これを 2 に設定することをお勧めします。また、キープアライブ接続数を 0 などに減らすこともお勧めします。
HTTP 1.0 スタイルの作業負荷では、多数の接続が確立され、終了されます。
サーバーが高負荷状態のときにブラウザから Web Server への接続でタイムアウトが発生する場合には、HTTP リスナーの待機キューサイズを 8192 などの大きな値に設定することで、HTTP リスナーのバックログキューのサイズを増やすことができます。
HTTP リスナーの待機キューは、ある待機ソケット上で保留される接続の最大数を指定します。バックログキューがいっぱいになった待機ソケット上で接続がタイムアウトすると、その接続は失敗します。
一般に、サーバーによる持続的接続の処理をチューニングする場合、スループットと待ち時間はトレードオフの関係になります。キープアライブポーリング間隔とタイムアウトによって待ち時間が決まります。これらの設定の値を小さくすることの狙いは、ページの読み込み時間を短縮するなど、低負荷システムでの待ち時間を短縮することです。これらの設定の値を増やすことの狙いは、サーバーが 1 秒間に処理できる要求の数を増やすなど、高負荷システムでの全体的なスループットを高めることです。ただし、待ち時間が長すぎるのにクライアントが少なすぎる場合には、サーバーが不必要にアイドル状態になるため、全体的なスループットが低下します。結論として、ある特定の負荷状態におけるキープアライブサブシステムの一般的なチューニング規則は、次のようになります。
アイドル状態の CPU 時間が存在する場合は、ポーリング間隔を減らします。
アイドル状態の CPU 時間が存在しない場合は、ポーリング間隔を増やします。
また、チャンクエンコーディングは、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 バイト未満にするべきです。
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 にオブジェクトを追加すれば、サーバーの実行中にファイルキャッシュを動的に監視および制御できます。
NameTrans 指令をデフォルトオブジェクトに追加します。
NameTrans fn="assign-name" from="/nsfc" name="nsfc"
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: キャッシュ内のファイルを一覧表示する。
?start: キャッシュを起動する。
?stop: キャッシュをシャットダウンする。
?list オプションを選択する場合、そのファイルリストには、ファイル名、一連のフラグ、現在のキャッシュエントリ参照数、ファイルのサイズ、および内部ファイル ID 値が含まれます。フラグは次のとおりです。
C: ファイルのコンテンツがキャッシュに書き込まれている。
D: キャッシュエントリが削除対象としてマークされている。
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 を変更するには、magnus.conf 内の NativePoolStackSize 指令を編集します。
NativePoolQueueSize は、スレッドプール用のキュー内で待機できるスレッドの数を決定します。プール内のすべてのスレッドがビジー状態になると、ネイティブプール内のスレッドを使用する必要のある次の要求処理スレッドは、キュー内で待機する必要があります。キューがいっぱいになると、次の要求処理スレッドがキューに入ろうとしても拒否され、最終的にそのスレッドはクライアントにビジー応答を返します。その後、そのスレッドは、キュー内で待機しながら拘束される代わりに、別の受信要求を自由に処理できるようになります。
NativePoolQueueSize を最大スレッド数の値よりも小さい値に設定すると、プールスレッドによるサービスを待機している要求の数がこの値を超えるたびに、サーバーは目的とする NSAPI 関数の代わりにビジー関数を実行します。デフォルトでは、「503 Service Unavailable」応答が返され、ログレベルの設定に応じたメッセージがログに記録されます。NativePoolQueueSize を最大スレッド数よりも大きい値に設定すると、ビジー関数が実行可能になる前にサーバーが接続を拒否します。
この値は、ネイティブスレッドを必要とするサービスを同時に求める要求の最大数を表します。負荷が高いためにシステムが要求を処理できない場合に、待機可能な要求の数を増やすと、要求の待ち時間が長くなり、利用可能なすべての要求スレッドが 1 つのネイティブスレッドを待機することになる可能性があります。一般に、この値は、ネイティブスレッドを必要とする要求を実行する同時ユーザーの最大数を予想し、その要求が拒否されるのを回避できるだけの大きな値に設定します。
この値と最大スレッド数の違いは、静的 HTML や画像ファイルなどの、非ネイティブスレッド要求のために予約される要求数にあります。予約を確保して要求を拒否することで、サーバーが静的ファイルの要求を処理し続けることを保証でき、動的コンテンツの高負荷時にサーバーが応答不能になるのを防ぐことができます。サーバーが常に接続を拒否する場合には、この値の設定が小さすぎるか、あるいはサーバーのハードウェアが過負荷状態になっています。
NativePoolQueueSize を変更するには、magnus.conf 内の NativePoolQueueSize 指令を編集します。
NativePoolMaxThreads は、ネイティブ (カーネル) スレッドプール内のスレッドの最大数を決定します。
値を大きくするほど、同時に実行可能な要求が多くなりますが、コンテキストの切り替えによるオーバーヘッドも大きくなります。したがって、値が大きいほど良いとは限りません。通常の場合、この数値を増やす必要はありませんが、CPU がまだ飽和状態に達しておらず、かつ待機中の要求が多数存在している場合には、この数値を増やすべきです。
NativePoolMaxThreads を変更するには、magnus.conf 内の NativePoolMaxThreads パラメータを編集します。
ネイティブ (カーネル) スレッドプール内のスレッドの最小数を決定します。
NativePoolMinThreads を変更するには、magnus.conf 内の NativePoolMinThreads パラメータを編集します。
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 のヒット率には、キャッシュ検索数に対するキャッシュヒット数が表示されます。管理コンソールの統計に基づいてこの数値を計算するには、「キャッシュヒットの合計」と「キャッシュミスの合計」を足したもので、「キャッシュヒットの合計」を割ります。
この設定はチューニング不可能です。
Async DNS enabled/disabled には、サーバーがオペレーティングシステムの同期リゾルバの代わりに独自の非同期 DNS リゾルバを使用するかどうかが表示されます。非同期 DNS はデフォルトで無効になっています。これが無効になっていると、このセクションが perfdump で表示されません。管理コンソールでこれを有効にするには、構成の「パフォーマンス」タブ ⇒「DNS」タブの「DNS 検索設定」の下で、「非同期 DNS」を選択します。コマンド行インタフェースでこれを有効にするには、wadm set-dns-prop を使って async プロパティーを true に設定します。
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 を参照してください。
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 アプリケーション統計が表示されるのは、管理コンソール、wadm get-config-stats コマンド、および stats-xml を使用する場合だけです。perfdump ではそれらは表示されません。
「共通操作」ページから「監視」タブを選択します。
構成の Web アプリケーション統計を表示するには、構成名をクリックします。インスタンスの Web アプリケーション統計を表示するには、「インスタンス」サブタブをクリックし、インスタンス名をクリックします。
「監視統計」ページで、「仮想サーバーの統計」をクリックします。
仮想サーバー名をクリックします。
「仮想サーバーの監視統計」ページで「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 ドライバを使って物理データベースへの接続を確立します。接続のプールが作成されるのは、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 リソース統計の例を示します。
表 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 統計は、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 リソースの属性のリストと、その値を設定する際のパフォーマンス上の考慮点を、次に示します。
サーバーインスタンスの寿命内でプールが維持する傾向のあるサイズ。プールの初期サイズでもあります。デフォルトは 8 です。この数値は、予期されるプールの平均サイズにできるだけ近い値にするべきです。高負荷下での使用が予期されるプールの場合、アプリケーションの寿命内での接続の作成やプールのサイズ変更が最小限に抑えられるよう、大きな数値を使用してください。小さい負荷が予期されるプールの場合、リソース消費が最小限に抑えられるよう、小さい数値を使用してください。
プールが任意の時点で持つことのできる接続の最大数。デフォルトは 32 です。プールまたはアプリケーションが持つことのできる接続リソースの量に制限を加える場合に、この設定を使用します。また、この制限は、過剰なリソース消費によるアプリケーションエラーを回避するためにも役立ちます。
未使用状態の接続がプール内にとどまることが保証される、秒単位の最大時間。このアイドルタイムアウトが経過すると、接続が自動的に閉じられます。必要であれば、閉じられた接続の代替として、最小接続数までの接続が新たに作成されます。この設定は、データベースサーバー側で適用される接続タイムアウトを制御するわけではありません。デフォルト値は 60 秒です。
この属性を –1 に設定すると、接続が閉じられなくなります。この設定は、高い要求が継続的に見込まれるようなプールに適しています。それ以外の場合は、使用不可能な接続がプール内に蓄積されないよう、このタイムアウトがデータベースサーバー側のタイムアウトよりも短くなるようにしてください (特定ベンダーのデータベース上でそのようなタイムアウトが構成されている場合)。
タイムアウトの発生までに要求がキュー内で接続を待機する時間 (秒)。このタイムアウトが経過すると、ユーザーにエラーが表示されます。デフォルトは 60 です。
この属性を 0 に設定すると、接続の要求が無制限に待機するようになります。また、この設定ではプールが接続タイマーを考慮する必要がなくなるため、パフォーマンスが改善する可能性もあります。
プール内の接続の健全性を判定する目的でプールによって使用される方法。デフォルトはオフです。
ある検証方法が使用される場合、プールは、アプリケーションに接続をリースする前に、その接続の妥当性検査を実行します。
効果やパフォーマンスへの影響は、選択する方法ごとに異なります。
検証方法が table の場合に検証に使用されるユーザー定義テーブル。デフォルトは test です。
この方法を使用する場合、使用されるテーブルは検証専用にするべきであり、かつテーブル内の行数は最小限に抑えるべきです。
無効な接続が見つかった場合に、プール内のすべての接続を再作成するのか、あるいは無効な接続のみを再作成するのかを示します。ユーザーが接続検証方法を選択した場合にのみ適用されます。デフォルトは無効です。
これを有効にした場合、すべての再作成が一度に行われ、接続を要求しているスレッドは多大な影響を受けます。これを無効にした場合、接続の再作成の負荷が、各接続を要求しているスレッド間で分散されます。
プール内のデータベース接続のトランザクション遮断レベルを指定します。
デフォルトでは、接続のデフォルトの遮断レベルがそのまま使用されます。これを任意の値に設定すると、メソッド呼び出しによるパフォーマンス低下が若干発生します。
トランザクション遮断レベルが指定された場合にのみ適用されます。デフォルトは無効です。
この設定を無効のままにすると、接続の作成時にのみ、遮断レベルが設定されます。有効にすると、接続がアプリケーションにリースされるたびに、レベルが設定されます。ほとんどの場合、この設定は無効のままにします。