プライマリ・コンテンツに移動
Oracle® Traffic Director管理者ガイド
11g リリース1 (11.1.1.9)
B66436-05
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

15.2 接続処理設定のチューニング

この項の内容は次のとおりです。

15.2.1 スレッド・プールおよび接続キューのチューニング

この項の内容は次のとおりです。

15.2.1.1 接続処理概要

クライアントがOracle Traffic DirectorインスタンスのHTTPリスナーにリクエストを送信すると、接続はHTTPリスナーに関連付けられているアクセプタ・スレッドによってまず受け入れられます。アクセプタ・スレッドは、接続を接続キューに入れ、次のクライアント・リクエストを待機します。スレッド・プールリクエスト処理スレッドは、接続キューから接続を取得し、リクエストを処理します。接続プールが無効化されている場合、アクセプタ・スレッド自体によって各リクエストが処理されることに注意してください。接続キューおよびリクエスト処理スレッドは存在しません。

図15-1は、接続処理を示しています。

図15-1 Oracle Traffic Directorの接続処理

図15-1の説明が続きます
「図15-1 Oracle Traffic Directorの接続処理」の説明

Oracle Traffic Directorインスタンスは、起動時に、各リスナー、および指定された最小リクエスト処理スレッド数を含むスレッド・プールについて、指定された数のアクセプタ・スレッドを作成します。

  • リスナーのアクセプタ・スレッド数が指定されていない場合、Oracle Traffic Directorではホスト上のCPUごとに1つのアクセプタ・スレッドが作成されます。

  • スレッド・プールの最小サイズが指定されていない場合、Oracle Traffic Directorでは、インスタンスが実行されているホスト上のプロセッサごとに1つのリクエスト処理スレッドが作成されます。

リクエスト・ロードが増加すると、Oracle Traffic Directorは、接続キューのリクエスト数をリクエスト処理スレッド数と比較します。キュー内のリクエスト数が、リクエスト処理スレッド数よりも多い場合、Oracle Traffic Directorはスレッド・プールの指定最大サイズまで、スレッドを追加作成します。

最大リクエスト処理スレッド数のデフォルト値が、プロセスで利用できる最大ファイル・ディスクリプタ数の4分の1を上回ることはありません。1、2個のCPUがある場合のデフォルトは256で、3、4個のCPUがある場合のデフォルトは512です。CPUが4個より多い場合のデフォルトは1024です。

スレッドの最大数は、同時に実行可能なセッション数のハード・リミットです。最大スレッド制限は、インスタンス内のすべての仮想サーバーにわたって適用されます。

15.2.1.2 インスタンスの接続キュー・メトリックの確認

接続キューの最大サイズが十分ではない場合、クライアント・リクエストは、ロードがピークの時間帯は却下される可能性があります。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
  • Current/Peak/Limit Queue Length行には、次の項目が示されます。

    • Current: 現在キュー内にある接続数。

    • Peak: キューに同時に存在できる最大接続数。

      ピークのキューの長さが制限に近い場合、接続キューのサイズが、ロードに対して十分ではないことを意味します。

    • Limit: 接続キューの最大サイズであり、スレッド・プール・キュー、最大スレッド数およびキープ・アライブ・キューのサイズの合計となります。

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

  • Average Queue Lengthは、直近の1分、5分および15分のそれぞれの間隔でのキュー内の平均接続数です。

  • Average Queueing Delayは、接続キュー内の接続がキュー内に留まった平均時間です。これは、リクエストがサーバーによって受け入れられた時点と、このリクエストの処理がリクエスト処理スレッドによって開始された時点の間の遅延時間を表します。平均キューイング遅延が、平均レスポンス時間と比較して相対的に大きい場合、スレッド・プール内のスレッド数を増やすことを検討してください。

15.2.1.3 インスタンスのスレッド・プール・メトリックの確認

プレーンテキストperfdumpレポートのSessionCreationInfoセクションで、インスタンスのスレッド・プール情報を、次の例に示すように確認できます。

SessionCreationInfo:
------------------------
Active Sessions 2187
Keep-Alive Sessions 0
Total Sessions Created 4016/4016
  • Active Sessionsは、現在リクエストを処理しているリクエスト処理スレッドの数です。

  • Keep-Alive Sessionsは、キープ・アライブ・セッションを提供するHTTPリクエスト処理スレッドの数を示しています。

  • Total Sessions Created

    • 最初の数値は、作成されたリクエスト処理スレッド数です。

    • 2番目の数値は、スレッド・プールに許可されている最大スレッド数で、スレッド・プールに構成されている最大スレッドおよびキープ・アライブ・スレッド数の合計です。

作成したリクエスト処理スレッドの合計数が、最大スレッド数に常に近い場合、スレッド制限を増やすことを検討してください。そうしないと、接続キューでのリクエストの待機時間が長くなる場合があり、接続キューが一杯になった場合は、その後のリクエストは受け入れられなくなります。平均キューイング遅延(15.2.1.2項を参照)が、平均レスポンス時間と比較して著しく大きい場合も、スレッド制限数を増やす必要があることを意味します。

15.2.1.4 スレッド・プールおよび接続キュー設定のチューニング

管理コンソールまたはCLIのいずれかを使用して、スレッド・プールおよび接続キュー設定を変更できます。

管理コンソールを使用したスレッド・プールおよび接続キュー設定の変更

管理コンソールを使用してスレッド・プール設定を変更するには、次の操作を行います。

  1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

  2. ページの左上隅にある「構成」ボタンをクリックします。

    使用可能な構成のリストが表示されます。

  3. 変更する構成を選択します。

  4. ナビゲーション・ペインで、「詳細設定」を展開し、HTTPを選択します。

    「HTTP設定」ページが表示されます。

  5. ページの「スレッド・プール」セクションに移動します。

  6. 変更するパラメータを指定します。

    画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

    フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

    「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

  7. 必要な変更を行った後、「保存」をクリックします。

    • 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

    • さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したスレッド・プールおよび接続キュー設定の変更

  • 現在のスレッド・プール設定を表示するには、次の例に示すようにget-thread-pool-propコマンドを実行します。

    tadm> get-thread-pool-prop --config=soa
    enabled=true
    stack-size=262145
    max-threads=20480
    queue-size=2000
    min-threads=20480
    
  • スレッド・プール設定を変更するには、set-thread-pool-propコマンドを実行します。

    たとえば、接続キュー・サイズを変更するには、次のコマンドを実行します。

    tadm> set-thread-pool-prop --config=soa queue-size=2000
    OTD-70201 Command 'set-thread-pool-prop' ran successfully.
    

    更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイします。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。

15.2.2 HTTPリスナー設定のチューニング

次は、パフォーマンスに影響する主要なHTTPリスナー・パラメータです。

  • リスナー・アドレス

    リスナー・アドレスは、IPアドレスとポート番号で構成されます。Oracle Traffic Directorインスタンスが実行中のホストは、複数のネットワーク・インタフェースと複数のIPアドレスを持つことができます。

    ホスト・マシンのすべてのネットワーク・インタフェース上のクライアント・リクエストをリスニングするように構成されているリスナーのIPアドレスは0.0.0.0となります。リスナーのIPアドレスとして0.0.0.0を指定すると便利ですが、結果として各接続に対して1つのシステム・コールが追加で必要になります。パフォーマンスの向上のためには、リスナーに実際のIPアドレスを指定することを検討してください。

  • アクセプタ・スレッド数

    アクセプタ・スレッドは、クライアント・リクエストを受信して、接続キューに入れます。Oracle Traffic Directorインスタンスが起動されると、指定された数のアクセプタ・スレッドが各リスナーに作成されます。リスナーのアクセプタ・スレッド数が指定されていない場合、Oracle Traffic Directorではホスト上のCPUごとに1つのアクセプタ・スレッドが作成されます。

    アクセプタ・スレッドの数が少なすぎると、受け入れられないクライアント・リクエストが発生する可能性がありますが、アイドル状態のアクセプタ・スレッドが多すぎても、不要な負荷がシステムにかかります。デフォルトである、1CPU当たり1つのアクセプタ・スレッドという設定は、ほとんどの状況で許容できるトレードオフです。

    比較的大量の接続をオープンおよびクローズする必要のある、HTTP 1.0のワークロードでは、デフォルトのアクセプタ・スレッド数である、1リスナー当たり1スレッドが準最適な設定です。アクセプタ・スレッド数を増やすことを検討してください。

  • リスニング・キュー・サイズ

    前述したように、アクセプタ・スレッドは、クライアント・リクエストを受信して、接続キューに入れます。オペレーティング・システムでアクセプタ・スレッドがスケジュールされていない場合、オペレーティング・システムのカーネルが、Oracle Traffic Directorプロセスにかわり、TCP接続を維持します。カーネルは、リスニング・キュー・サイズによって指定されている制限まで接続を受け入れることができます。

    HTTP 1.0スタイルのワークロードには、確立および終了した多くの接続が含まれる場合があります。このため、Oracle Traffic Directorインスタンスに大きな負荷がかかり、クライアントで接続タイムアウトが発生する場合は、リスニング・キュー・サイズをより大きい値に設定して、HTTPリスナー・バックログ・キューのサイズを増やすことができます。

プレーンテキストperfdumpレポートには、次の例に示すように、構成内の各HTTPリスナーに対するIPアドレスおよびアクセプタ・スレッドの数が示されます。

ListenSocket ls1:
------------------------
Address                   https://0.0.0.0:1904
Acceptor Threads          1
Default Virtual Server    net-soa

10.3項「リスナーの変更」の説明に従い、管理コンソールまたはCLIを使用して、HTTPリスナーの設定を変更できます。

15.2.3 キープ・アライブ設定のチューニング

この項の内容は次のとおりです。

15.2.3.1 キープ・アライブ接続について

HTTP 1.0およびHTTP 1.1は、単一のHTTP接続での複数のリクエストの送信をサポートしています。HTTP 1.0ではキープ・アライブと呼ばれていたこの機能は、HTTP 1.1では永続接続と呼ばれ、Oracle Traffic Directorではデフォルトで有効化されています。

元のリクエストを処理した後も接続をアクティブのまま保持することで、その後の類似したリクエストに対するTCP接続の作成およびクローズに関連する時間およびオーバーヘッドを削減できます。ただし、受信するリクエストが少ない、またはない場合、キープ・アライブ接続はシステムに対して不要な負荷となります。

この問題を回避するために、待機中のキープ・アライブ接続の最大数を指定できます。キープ・アライブ・リクエストが受信されたとき、リクエスト待機中のオープン接続が、指定した最大数を超えて存在する場合、最も古い接続はクローズされます。また、一定期間非アクティブであるキープ・アライブ接続をクローズする場合のその期間を指定できます。

15.2.3.2 キープ・アライブ接続の設定およびメトリックの確認

プレーンテキストperfdumpレポートには、次の例に示すように、現在のキープ・アライブ設定およびメトリックが示されます。

KeepAliveInfo:
--------------------
KeepAliveCount 26/60000
KeepAliveHits 154574634
KeepAliveFlushes 0
KeepAliveRefusals 0
KeepAliveTimeouts 5921
KeepAliveTimeout 120 seconds

perdumpレポートのKeepAliveInfoセクションには、次のように表示されます。

  • KeepAliveCount:

    • 最初の数値は、キープ・アライブ・モードの接続数です。

    • 2番目の数値は、許可されている最大キープ・アライブ接続数です。

  • KeepAliveHitsは、キープ・アライブ状態の接続で正常に受信されたリクエスト数です。

    KeepAliveHitsが、KeepAliveFlushesと比較して高い場合、キープ・アライブ接続が十分に利用されていることを示します。

    KeepAliveHitsが低い場合、大量のキープ・アライブ接続がアイドル状態のままであり、システム・リソースが不必要に消費されていることを示します。この状況に対応するには、次の方法があります。

    • キープ・アライブ状態の接続数を少なくするために、キープ・アライブ接続の最大数を減らします。

      最大接続数設定で指定された接続数は、キープ・アライブ・スレッド間で均等に分配されることに注意してください。最大接続数設定がキープ・アライブ・スレッド設定で均等に分配されていない場合、サーバーではキープ・アライブ接続の最大数を少し上回る数が許可されます。

    • キープ・アライブ接続が長時間アイドル状態のままとならないように、KeepAliveTimeoutを短くします。KeepAliveTimeoutの値が非常に小さい場合、新規TCP接続の設定におけるオーバーヘッドが増加することに注意してください。

  • KeepAliveFlushesは、クライアントがキープ・アライブをリクエストした接続をサーバーがクローズした回数です。

    キープ・アライブ・フラッシュを減らすには、キープ・アライブ最大接続数を増やします。


    注意:

    UNIX/Linuxシステムで、キープ・アライブ最大接続数が非常に大きく設定されている場合、サーバーのオープン・ファイル・ディスクリプタが不足する場合があります。一般的に、1024がUNIX/Linuxでのオープン・ファイル数の制限であるため、キープ・アライブの最大接続数を500よりも増やすことはお薦めしません。かわりに、15.3項「ファイル・ディスクリプタ制限のチューニング」の説明に従い、ファイル・ディスクリプタ制限を増やすことができます。

  • KeepAliveRefusalsは、考えられる理由の1つとしてKeepAliveCountがキープ・アライブ最大接続数を超えたために、サーバーが接続をキープ・アライブ・スレッドに渡すことができなかった回数です。この値が大きい場合、キープ・アライブ接続の最大数を増やすことを検討してください。

  • KeepAliveTimeoutsは、前回のKeepAliveTimeout期間中に、キープ・アライブ接続でリクエストが受信されなかったため、アイドル状態のキープ・アライブ接続がクローズされた回数です。

  • KeepAliveTimeoutは、アイドル状態のキープ・アライブ接続がクローズされるまでの秒単位での期間です。

    構成可能でパフォーマンスに影響を及ぼすが、perfdumpレポートには表示されない、もう1つのパラメータとして、キープ・アライブ・ポーリング間隔がありますが、これはKeepAliveTimeoutとともに、待機時間およびスループットを制御します。ポーリング間隔およびタイムアウト期間を短くすると、負荷の小さいシステムの待機時間が短くなります。これらの設定の値を大きくすると、負荷の大きいシステムの集約スループットが向上します。ただし、待機時間が長く、クライアント数が少なすぎる場合、サーバーが不必要にアイドル状態のままとなるため集約スループットに悪影響が出ます。したがって、一定の負荷で、アイドルのCPU時間がある場合ポーリング間隔を短くし、アイドル状態のCPU時間がない場合ポーリング間隔を長くします。

15.2.3.3 キープ・アライブ設定のチューニング

管理コンソールまたはCLIのいずれかを使用して、キープ・アライブ設定をチューニングできます。

管理コンソールを使用したキープ・アライブ設定の変更

管理コンソールを使用してキープ・アライブ設定を変更するには、次の操作を行います。

  1. 2.3.2項「管理コンソールへのアクセス」の説明に従って、管理コンソールにログインします。

  2. ページの左上隅にある「構成」ボタンをクリックします。

    使用可能な構成のリストが表示されます。

  3. 変更する構成を選択します。

  4. ナビゲーション・ペインで、「詳細設定」を展開し、HTTPを選択します。

    「HTTP設定」ページが表示されます。

  5. ページの「キープ・アライブ」セクションに移動します。

  6. 変更するパラメータを指定します。

    画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。

    フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「保存」ボタンが有効になります。

    「リセット」ボタンをクリックすることで、いつでも変更を破棄できます。

  7. 必要な変更を行った後、「保存」をクリックします。

    • 更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。

    • さらに、「デプロイメント保留中」メッセージが、メイン・ペインの上部に表示されます。4.3項「構成のデプロイ」の説明に従い、「変更のデプロイ」をクリックして更新された構成を即座にデプロイすることも、さらに変更を行いその後でデプロイすることもできます。

CLIを使用したキープ・アライブ設定の変更

  • 現在のキープ・アライブ設定を表示するには、次の例に示すようにget-keep-alive-propコマンドを実行します。

    tadm> get-keep-alive-prop --config=soa
    enabled=true
    threads=20
    max-connections=2000
    poll-interval=0.002
    timeout=31
    
  • キープ・アライブ設定を変更するには、set-keep-alive-propコマンドを実行します。

    たとえば、キープ・アライブ接続の最大数を変更するには、次のコマンドを実行します。

    tadm> set-keep-alive-prop --config=soa max-connections=2000OTD-70201 Command 'set-keep-alive-prop' ran successfully.
    

    更新された構成を有効にするには、deploy-configコマンドを使用して、構成をOracle Traffic Directorインスタンスにデプロイします。

この項で説明されたCLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照するか、--helpオプションを付けてコマンドを実行してください。