| Oracle® Fusion Middleware Oracle Traffic Directorの管理 12c (12.2.1.3.0) E90199-04 |
|
 前 |
 次 |
この章の構成は、次のとおりです。
この章で提供されるチューニングの提案内容の実行結果は、各ユーザーの環境に応じて異なる場合があります。ニーズに適したチューニング・パラメータを決定する際には、次のガイドラインに留意してください。
1回ごとに1つのパラメータを調整します
可能な限り、1回ごとに1つの調整を行ってください。各変更の前と後でパフォーマンスを計測し、大きな改善が見られない変更は元に戻します。
パフォーマンス・ベンチマークの作成に使用できるテスト・ケースを設定します。
パラメータを変更する前に、パフォーマンスに及ぼす変更の影響をテストするためのテスト・ケースを設定し、可能な場合は自動化します。
段階的にチューニングします
量的なパラメータを調整する場合、小さい増分単位で変更してください。これは、最適な設定を迅速に特定するのに最も適切な方法です。
ハードウェアまたはソフトウェアを変更した後は、再び最初から確認します
ハードウェアまたはソフトウェアのアップグレードなど、主なシステム変更ごとに、前のチューニングの変更が適用できるかどうかを確認します。
オペレーティング・システムでは、ファイル・ディスクリプタを使用して、ファイルシステムのファイル、および接続やリスナー・ソケットなどの擬似ファイルを処理します。
Oracle Traffic Directorインスタンスの起動後、ファイル・ディスクリプタ関連の値の自動構成が行われる際に、次のパラメータが考慮されます。
HTTP処理スレッド(<thread-pool>)
すべての仮想サーバーのアクセス・ログ件数(<access-log>)
リスナー(<http-listener>、<tcp-listener>)
キープ・アライブ接続(<keep-alive>)
オリジン・サーバー・プールの数(<origin-server-pool>)
オリジン・サーバーの数(<origin-server>)
オリジン・サーバーの接続(<origin-server>/<max-connections>)
TCP処理スレッド(<tcp-thread-pool>)
ファイル・ディスクリプタを必要とする主要なOracle Traffic Directorオブジェクトは、キープ・アライブ接続、キューに入れられた接続、およびオリジン・サーバーへの接続です。これらのオブジェクトの制限を明示的に指定しない場合、Oracle Traffic Directorインスタンスが起動すると、制限(最大キープ・アライブ接続、接続キューのサイズ、および各オリジン・サーバーの最大接続数)が、システム内で使用可能なファイル・ディスクリプタの合計数に基づいて自動的に構成されます。
ファイル・ディスクリプタ制限に異常に高い値が設定されている場合、未指定のパラメータの自動構成が原因でOracle Traffic Directorインスタンスがメモリーを過剰消費したり、最適な構成を得られないことがあります。この問題を回避するため、ファイル・ディスクリプタ制限が高いシステムではこれらのパラメータ値を明示的に指定します。
たとえば、max-threads * 4がプロセスで利用できる最大ファイル・ディスクリプタ数よりも小さくなるのが理想です。たとえば、ファイル・ディスクリプタ制限が65536に設定されている場合にmax-threadsを20000に設定すると、最適なチューニングを得られません。これは、ワーカー・スレッド用として80000 (20000*4=80000)がファイル・ディスクリプタを使い切って/予約してしまい、他のサブシステム用に残るファイル・ディスクリプタが少なくなるためです。そのため、max-threadsに高い値を設定する場合は、何回かテストを行ったうえで設定する必要があります。
割り当てられたファイル・ディスクリプタ数は、システムでサポート可能な制限を超えられません。ファイル・ディスクリプタの現在のシステム制限を確認するには、次のコマンドを実行します。
$ cat /proc/sys/fs/file-max 2048
使用可能なファイル・ディスクリプタのうち現在使用されている数を確認するには、次のコマンドを実行します。
$ cat /proc/sys/fs/file-nr
このコマンドによって、次のような出力が返されます。
625 52 2048
この例では、625は割当て済ファイル・ディスクリプタ数、52は空きの割当て済ファイル・ディスクリプタ数、2048はシステムでサポートされているファイル・ディスクリプタの最大数です。
注意:
Solarisでは次のコマンドを使用して、システム全体で使用中のファイル・ディスクリプタを検出できます。
# echo ::kmastat | mdb -k | grep file_cache
このコマンドによって、次のような出力が返されます。
file_cache 56 1154 1305 73728B 659529 0
この例では、1154が使用中のファイル・ディスクリプタの数、1305が割当済のファイル・ディスクリプタの数です。Solarisでは、オープン・ファイル・ディスクリプタの最大数の設定がないことに注意してください。RAMに空き領域があるかぎり、要求に応じて割り当てられます。
割当て済ファイル・ディスクリプタがシステムの制限に達すると、ファイルを開くときに次のエラー・メッセージがシステム・コンソールに表示されます。
Too many open files in system.
次のメッセージがサーバー・ログに書き込まれます。
[ERROR:16] [OTD-10546] Insufficient file descriptors for optimum configuration.
これは、システムではこれ以上ファイルを開くことができないという重大な問題です。この問題を回避するために、ファイル・ディスクリプタ制限を合理的な数まで増やすことを検討してください。
Linuxでファイル・ディスクリプタ数を変更するには、次の操作をrootユーザーとして行います。
thumbのおおよそのルールとして、thread-pool要素、max-threads * 4がプロセスで利用できる最大ファイル・ディスクリプタ数よりも小さくなるようにするというルールがあります。これはつまり、max-threadsを最大ファイル・ディスクリプタ数の1/5未満にするということです。
たとえば、ファイル・ディスクリプタ制限が65536に設定されている場合にmax-threadsを20000に設定すると、最適なチューニングを得られません。これは、ワーカー・スレッド用として20000*4=80000がファイル・ディスクリプタを使い切って/予約してしまい、他のサブシステム用にファイル・ディスクリプタがほとんど残らないためです。
max-threadsに高い値を設定する場合は、必ず事前にテストを行ってください。1つのプロセスに数万のスレッドが存在する状態はパフォーマンスに影響を及ぼすことがあります。
この項では、次の項目について説明します。
クライアントがOracle Traffic DirectorインスタンスのHTTPリスナーにリクエストを送信すると、接続はHTTPリスナーに関連付けられているアクセプタ・スレッドによってまず受け入れられます。アクセプタ・スレッドは、接続を接続キューに入れ、次のクライアント・リクエストを待機します。スレッド・プールのリクエスト処理スレッドは、接続キューから接続を取得し、リクエストを処理します。接続プールが無効化されている場合、アクセプタ・スレッド自体によって各リクエストが処理されることに注意してください。接続キューおよびリクエスト処理スレッドは存在しません。
「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です。
スレッドの最大数は、同時に実行可能なセッション数のハード・リミットです。最大スレッド制限は、インスタンス内のすべての仮想サーバーにわたって適用されます。
プレーンテキスト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番目の数値は、スレッド・プールに許可されている最大スレッド数で、スレッド・プールに構成されている最大スレッドおよびキープ・アライブ・スレッド数の合計です。
作成したリクエスト処理スレッドの合計数が、最大スレッド数に常に近い場合、スレッド制限を増やすことを検討してください。そうしないと、接続キューでのリクエストの待機時間が長くなる場合があり、接続キューが一杯になった場合は、その後のリクエストは受け入れられなくなります。平均キューイング遅延(「インスタンスの接続キュー・メトリックの確認」を参照)が、平均レスポンス時間と比較して著しく大きい場合も、スレッド制限数を増やす必要があることを意味します。
接続キューの最大サイズが十分ではない場合、クライアント・リクエストは、ロードがピークの時間帯は却下される可能性があります。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は、接続キュー内の接続がキュー内に留まった平均時間です。これは、リクエストがサーバーによって受け入れられた時点と、このリクエストの処理がリクエスト処理スレッドによって開始された時点の間の遅延時間を表します。平均キューイング遅延が、平均レスポンス時間と比較して相対的に大きい場合、スレッド・プール内のスレッド数を増やすことを検討してください。
次の項の説明に従い、Fusion Middleware ControlまたはWLSTのいずれかを使用して、スレッド・プールおよび接続キューの設定を変更できます。
Fusion Middleware Controlを使用したスレッド・プールおよび接続キュー設定の変更
Fusion Middleware Controlを使用してスレッド・プール設定を変更するには、次を実行します。
WLSTを使用したスレッド・プールおよび接続キュー設定の変更
現在のスレッド・プール設定を表示するには、次の例に示すように、otd_getHttpThreadPoolPropertiesまたはotd_getTcpThreadPoolPropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
otd_getHttpThreadPoolProperties(props)
enabled=true
queue-size=2000
min-threads=20480
max-threads=20480
stack-size=262145
スレッド・プール設定を変更するには、次の例に示すように、otd_setHttpThreadPoolPropertiesまたはotd_setTcpThreadPoolPropertiesコマンドを実行します。
たとえば、HTTP処理スレッドのスタック・サイズを変更するには、次のコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['stack-size'] = '8192'
otd_setHttpThreadPoolProperties(props)
次は、パフォーマンスに影響する主要な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
「リスナーの変更」の説明に従い、Fusion Middleware ControlまたはWLSTを使用してHTTPリスナーの設定を変更できます。
この項では、次の項目について説明します。
HTTP 1.0およびHTTP 1.1は、単一のHTTP接続での複数のリクエストの送信をサポートしています。HTTP 1.0ではキープ・アライブと呼ばれていたこの機能は、HTTP 1.1では永続接続と呼ばれ、Oracle Traffic Directorではデフォルトで有効化されています。
元のリクエストを処理した後も接続をアクティブのまま保持することで、その後の類似したリクエストに対するTCP接続の作成およびクローズに関連する時間およびオーバーヘッドを削減します。ただし、受信するリクエストが少ない、またはない場合、キープ・アライブ接続はシステムに対して不要な負荷となります。
図17-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よりも増やすことはお薦めしません。かわりに、「ファイル・ディスクリプタ制限のチューニング」の説明に従い、ファイル・ディスクリプタ制限を増やすことができます。
KeepAliveRefusalsは、考えられる理由の1つとしてKeepAliveCountがキープ・アライブ最大接続数を超えたために、サーバーが接続をキープ・アライブ・スレッドに渡すことができなかった回数です。この値が大きい場合、キープ・アライブ接続の最大数を増やすことを検討してください。
KeepAliveTimeoutsは、前回のKeepAliveTimeout期間中に、キープ・アライブ接続でリクエストが受信されなかったため、アイドル状態のキープ・アライブ接続がクローズされた回数です。
KeepAliveTimeoutは、アイドル状態のキープ・アライブ接続がクローズされるまでの秒単位での期間です。
構成可能でパフォーマンスに影響を及ぼすが、perfdumpレポートには表示されない、もう1つのパラメータとして、キープ・アライブ・ポーリング間隔がありますが、これはKeepAliveTimeoutとともに、待機時間およびスループットを制御します。ポーリング間隔およびタイムアウト期間を短くすると、負荷の小さいシステムの待機時間が短くなります。これらの設定の値を大きくすると、負荷の大きいシステムの集約スループットが向上します。ただし、待機時間が長く、クライアント数が少なすぎる場合、サーバーが不必要にアイドル状態のままとなるため集約スループットに悪影響が出ます。したがって、一定の負荷で、アイドルのCPU時間がある場合ポーリング間隔を短くし、アイドル状態のCPU時間がない場合ポーリング間隔を長くします。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、キープ・アライブ設定をチューニングできます。
Fusion Middleware Controlを使用してキープ・アライブ設定を変更するには、次を実行します。
現在のキープ・アライブ設定を表示するには、次の例に示すように、otd_getKeepalivePropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
otd_getKeepaliveProperties(props)
enabled=true
threads=20
max-connections=2000
timeout=30
poll-interval=0.001
キープ・アライブ設定を変更するには、otd_setKeepalivePropertiesコマンドを実行します。
たとえば、キープ・アライブ・サブシステムの最大スレッド数を変更するには、次のコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['threads'] = '128'
otd_setKeepaliveProperties(props)
Oracle Traffic Directorインスタンスがリクエストおよびレスポンスの処理に費やす時間を最適化するために、リクエストとレスポンスのヘッダー・サイズ、リクエストに許可されているヘッダー・フィールド数、およびOracle Traffic DirectorがHTTPリクエストの本文とヘッダーの受信を待機する時間などのパラメータを構成できます。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、HTTPリクエストおよびレスポンスの制限の変更を表示できます。
Fusion Middleware Controlを使用したHTTPリクエスト/レスポンスの制限の表示および変更
WLSTを使用したHTTPリクエスト/レスポンスの制限の表示および変更
現在の設定を表示するには、次の例に示すように、otd_getHttpPropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
otd_getHttpProperties(props)
server-header=Oracle Traffic Director/12.2.1
etag=true
request-header-buffer-size=8192
strict-request-headers=false
websocket-strict-upgrade=false
discard-misquoted-cookies=true
max-request-headers=64
body-buffer-size=1024
output-buffer-size=8192
max-unchunk-size=8192
unchunk-timeout=60
io-timeout=30
request-body-timeout=-1
request-header-timeout=30
ecid=true
favicon=true
リクエストおよびレスポンスの制限を変更するには、otd_setHttpPropertiesコマンドを実行します。
たとえば、チャンク解除タイムアウトを変更するには、次のコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['unchunk-timeout'] = '120'
otd_setHttpProperties(props)
DNSキャッシュを利用すると、Oracle Traffic Directorがクライアント・ホスト名をIPアドレスに解決するために実行する必要があるDNS参照の回数が削減されます。Oracle Traffic Directorでは、DNSキャッシュはデフォルトで有効化されており、IPアドレスとDNS名のマッピングが格納されています。DNSキャッシュ内の各エントリは、単一IPアドレスまたはDNS名参照を表します。DNSキャッシュは、DNS参照が有効化されており、Oracle Traffic Directorによって、DNS参照を必要とする操作(クライアントのIPアドレスおよびホスト名のアクセス・ログへの記録など)が実行される場合にのみ使用されます。
DNSキャッシュ・ヒット率を高くするには、Oracle Traffic Directorに同時にアクセスする可能性のあるクライアントの最大数に対して、キャッシュのサイズを、IPアドレスとDNS名のマッピングを十分に格納できる大きさにする必要があります。DNSキャッシュに許可されている最大エントリ数およびキャッシュ失効時間をチューニングできます。キャッシュ・サイズを大きくしすぎると、メモリーが無駄に消費される可能性があることに注意してください。
この項では、次の項目について説明します。
DNSキャッシュ設定の表示
構成の現在のDNSキャッシュ設定を表示するには、次の例に示すように、otd_getDnsCachePropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
otd_getDnsCacheProperties(props)
enabled=true
max-age=120
max-entries=1024
DNSキャッシュ・メトリックの表示
プレーンテキストperfdumpレポートで、現在のDNSキャッシュ使用量およびヒット率を、次の例に示すように表示できます。
DNSCacheInfo: ------------------ enabled yes CacheEntries 0/1024 HitRatio 0/0 ( 0.00%) Async DNS disabled
最初の行は、DNSキャッシュが有効化されているかどうかを示します。
CacheEntriesは、DNSキャッシュに現在存在するエントリ数、および許可されている最大エントリ数を示します。
HitRatioは、DNSキャッシュ参照回数と比較したキャッシュ・ヒット数です。
最後の行は、非同期DNS参照が有効化されているかどうかを示します。
Oracle Traffic Director独自の非同期リゾルバ、またはオペレーティング・システムの同期リゾルバのいずれかを使用して、DNS参照を実行するようにOracle Traffic Directorを構成できます。オペレーティング・システムのリゾルバを使用して実行するDNS参照の方が速度は速くなります。
Fusion Middleware Controlを使用したDNSキャッシュ設定の構成
Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成のDNSキャッシュ設定を構成できます。
Fusion Middleware Controlを使用してDNSキャッシュ設定を構成するには、次を実行します。
WLSTを使用したDNSキャッシュ設定の構成
構成のDNSキャッシュ設定を変更するには、otd_setDnsCachePropertiesコマンドを実行します。
たとえば、次のコマンドでは、DNSルックアップの結果をキャッシュする最大時間が240秒に変更されます。
props = {}
props['configuration'] = 'foo'
props['max-age'] = '240'
otd_setDnsCacheProperties(props)
この項では、次の項目について説明します。
HTTPS接続の最初のSSL/TLSハンドシェイク・プロセス中、クライアントとサーバーは、使用する暗号スイート、ならびに暗号化/復号化およびMAC鍵(「SSL/TLSの概念」を参照)についてネゴシエートします。このアクティビティは、RSAまたはECCのどちらの秘密鍵が使用されているか、および鍵のサイズに応じて、かなりのCPU時間を必要とします。
最初のSSL/TLSハンドシェイクにより、一意のSSL/TLSセッションIDが生成されます。SSL/TLSセッションIDがキャッシュされた場合、次に同じHTTPSクライアントが新しいソケット接続をオープンする際、サーバーはキャッシュからSSL/TLSセッションIDを取得し、最初のハンドシェイクよりもCPUへの負荷が少ない略式のSSL/TLSハンドシェイクを実行することで、接続の確立に要する時間を短縮できます。
SSL/TLSセッションのキャッシュは、Oracle Traffic Directorではデフォルトで有効化されています。SSL/TLSが有効化されているリスナーで新しい接続が確立されるとき、Oracle Traffic Directorは、SSL/TLSキャッシュにクライアントのセッションIDが含まれているかどうかをチェックします。クライアントのセッションIDがキャッシュ内に存在していて有効な場合、Oracle Traffic Directorは、そのセッションの再利用をクライアントに許可します。
SSL/TLSセッション・キャッシュ内の最大エントリ数、およびSSL/TLSセッションIDがキャッシュ内に格納される期間を構成できます。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、構成のSSL/TLSセッションのキャッシュ設定を構成できます。
Fusion Middleware Controlを使用してSSL/TLSセッションのキャッシュ設定を構成するには、次を実行します。
「Fusion Middleware Controlの表示」の説明に従って、Fusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
変更する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「詳細構成」→「設定」を選択します。
ページの「SSL/TLSキャッシュ」セクションに移動します。
変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「適用」ボタンが有効になります。
「元に戻す」ボタンをクリックすることで、いつでも変更を破棄できます。
必要な変更を行った後、「適用」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。
構成の現在のSSL/TLSキャッシュ設定を表示するには、次の例に示すように、otd_getSslSessionCachePropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
otd_getSslSessionCacheProperties(props)
enabled=true
max-entries=10000
SSL/TLSセッション・キャッシュ設定を変更するには、otd_setSslSessionCachePropertiesコマンドを実行します。
たとえば、次のコマンドでは、SSL/TLSセッション・キャッシュに許可された最大エントリ数が20000に変更されます。
props = {}
props['configuration'] = 'foo'
props['max-entries'] = '20000'
otd_setSslSessionCacheProperties(props)
強力な暗号およびサイズの大きい秘密鍵を使用すると、SSL/TLS接続のセキュリティはより安全に保護されますが、パフォーマンスに影響を及ぼします。
SSL/TLS接続において、特定の暗号(AESなど)では、より強力な暗号(3DESなど)よりもデータ転送に必要な演算リソースが少なくて済みます。「厳密なSNIホスト一致」が有効化されているリスナーでSSL/TLS暗号を選択する場合、この点を考慮してください。
リスナーに対する暗号の構成の詳細は、HTTP/TCPリスナーのSSLの構成を参照してください。
最初のSSL/TLSハンドシェイク・プロセスでは、鍵サイズの小さいRSA証明書(2048ビット)の方が鍵サイズの大きい証明書(3072および4096ビット)よりもかかる時間が短くなります。
自己署名証明書および証明書署名リクエストの作成の詳細は、「証明書の管理」を参照してください。
アクセス・ログには、サーバーへのクライアント・リクエストおよびサーバーからのレスポンスについての情報が含まれます。Oracle Traffic Directorインスタンスのクライアント・リクエストの受信率が非常に高い場合、これは、本番環境では一般的な状況ですが、ディスク上のログ・ファイルにエントリが書き込まれる頻度が高くなります。ディスクへの頻繁な書込みは、サーバーのパフォーマンスに影響する可能性のある、I/Oに負荷がかかるアクティビティです。
Oracle Traffic Directorがディスク上のアクセス・ログにエントリを書き込む頻度を減らすために、アクセス・ログの更新内容をバッファできます。Oracle Traffic Directorでは、アクセス・ログのバッファリングはデフォルトで有効化されます。
アクセス・ログ・バッファ・サイズ、1サーバー当たりのアクセス・ログ・バッファ数、およびエントリがバッファ内に保持される最大期間の制限を指定できます。バッファ・サイズ、バッファ数、またはバッファ内のエントリの経過時間が、指定した制限に到達すると、Oracle Traffic Directorは、バッファされたデータをディスク上のアクセス・ログに書き込みます。
Fusion Middleware ControlまたはWLSTのいずれかを使用して、アクセス・ログ・バッファ設定をチューニングできます。
Fusion Middleware Controlを使用したアクセス・ログ・バッファ設定の構成
Fusion Middleware Controlを使用してアクセス・ログ・バッファ設定を構成するには、次を実行します。
WLSTを使用したアクセス・ログ・バッファ設定の構成
現在のアクセス・ログ・バッファ・プロパティを表示するには、次の例に示すように、otd_getAccessLogBufferPropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
otd_getAccessLogBufferProperties(props)
enabled=true
buffer-size=8192
direct-io=false
max-buffers=1000
max-buffers-per-file=default
max-age=1
アクセス・ログ・バッファ・プロパティを変更するには、次の例に示すように、otd_setAccessLogBufferPropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['max-buffers'] = '2000'
otd_setAccessLogBufferProperties(props)
ログの表示、ログ・プリファレンスの構成、ログのローテーションなどの詳細は、「ログの管理」を参照してください。
圧縮されたオブジェクトは、少ないラウンドトリップで、より速くクライアントに送信されるため、高価なハードウェアへの投資を増やすことなく全体の待機時間が削減されます。
各Oracle Traffic Director仮想サーバーに固有の圧縮ルールを1つ以上作成し、すべてのリクエストに適用するように、または指定された条件に一致するリクエストのみに適用するように構成できます。
注意:
GIF、JPEGおよびPNGイメージ、ならびにZIPされたファイルなどの特定のファイルは、すでに圧縮されているか、それ以上圧縮することはできません。Oracle Traffic Directorでこのようなファイルを圧縮するように指定すると、圧縮の利点を得られずに追加のオーバーヘッドが発生します。したがって、仮想サーバーで圧縮ルールを作成する場合は、このようなファイルは除外してください。
各圧縮ルールでは、次のパラメータも指定できます。
スケール1から9の圧縮レベル。レベル1では圧縮時間は最短で、レベル9では圧縮率は最高になります。
圧縮レベルが高くなるほど、圧縮プロセス中により多くのCPUリソースが消費されますが、圧縮されたコンテンツの送信に必要な帯域幅は比較的小さくて済みます。一方、圧縮レベルが低い場合は、比較的CPUへの負荷が小さくなりますが、圧縮後のコンテンツの送信に必要な帯域幅が大きくなります。圧縮レベルを選択するときは、環境内で、CPUリソースとネットワークの帯域幅のいずれがより高価であるかを考慮してください。
CPUの使用量がより高価である場合、低い圧縮レベルを選択します。
ネットワークの帯域幅が主な制限事項である場合、高い圧縮レベルを選択します。
1回で圧縮するバイト数(フラグメント・サイズ)。
Vary: Accept-Encodingヘッダーをレスポンス内に含めるかどうか。
Vary: Accept-Encodingヘッダーは、クライアントとOracle Traffic Director間に存在するプロキシに、コンテンツの解凍が不可なクライアントに圧縮済コンテンツを提供しないように指示します。
Fusion Middleware Controlを使用した圧縮ルールの構成
Fusion Middleware Controlを使用して圧縮ルールを作成するには、次を実行します。
「グラフィカル・ユーザー・インタフェース - Fusion Middleware Control」の説明に従って、Fusion Middleware Controlにログインします
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
圧縮ルールを作成する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。
ナビゲーション・ペインで、「仮想サーバー」を展開し、圧縮ルールを作成する仮想サーバーの名前を展開して、「圧縮」を選択します。
「圧縮ルール」ページが表示されます。仮想サーバーに現在定義されている圧縮ルールがリストされ、その圧縮ルールが有効化されているかどうかが示されます。
圧縮ルールの作成
「新規圧縮ルール」をクリックします。
「新規圧縮ルール」ダイアログ・ボックスが表示されます。
注意:
小文字のみ使用できます。値に大文字が含まれる場合は、通知されることなく小文字に変更されます。「次へ」をクリックします。
条件を適用する場合は、「式の編集」を選択します。「新規式」ペインで「作成」ボタンを選択して新しいページを表示し、各ドロップダウン・リストから「変数」、「関数」および「演算子」を選択し、「値」フィールドに値を入力します。
複数の式を構成する場合は、ドロップダウン・リストでand/or演算子を選択します。同様に、指定した式が偽に評価されるときにルートを適用する場合は、Not演算子を使用します。
条件を手動で入力するには、ページの右上隅にある「手動編集」ボタンをクリックします。「条件」フィールドで、ルールが適用される条件を指定します。条件式の作成の詳細は、「条件」フィールドの近くにあるヘルプ・ボタンをクリックするか、Oracle Traffic Director構成ファイル・リファレンスの変数、式および文字列の補間の使用を参照してください。
「OK」をクリックして、「圧縮ルールの作成」をクリックします。
作成したキャッシュ・ルールが「圧縮ルール」ページに表示されます。
圧縮ルールの編集
圧縮ルールを有効化または無効化する、あるいはルールの設定を変更するには、次の操作を行います。
変更する圧縮ルールの「名前」をクリックします。
「圧縮ルールの編集」ダイアログ・ボックスが表示されます。
注意:
条件ビルダーにアクセスして条件を編集するには、「条件を満たすリクエスト」を選択し、「編集」をクリックします。条件ビルダーでは古い式を削除したり、新しい式を作成したりできます。
変更するパラメータを指定します。
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。
「取消」ボタンをクリックすることで、いつでも変更を破棄できます。
必要な変更を行った後、「OK」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。
圧縮ルールの削除
圧縮ルールを削除するには、「削除」ボタンをクリックします。確認プロンプトで、「はい」をクリックします。
WLSTを使用した圧縮ルールの構成
仮想サーバーの圧縮ルールを作成するには、otd_createCompressionRuleコマンドを実行します。
たとえば、次のコマンドでは、構成fooの仮想サーバーbarに対してcompress-docsという名前のルールが作成され、このルールでは、式$uri='^/docs'がtrueと評価されるリクエストがキャッシュされます。
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compress-docs'
props['condition'] = '$uri='^/docs''
otd_createCompressionRule(props)
conditionプロパティの値は、正規表現にする必要があることに注意してください。条件式の作成の詳細は、Oracle Traffic Director構成ファイル・リファレンスの変数、式および文字列の補間の使用を参照してください。
仮想サーバーに定義されている圧縮ルールのリストを表示するには、次の例に示すように、otd_listCompressionRulesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
otd_listCompressionRules(props)
compress-docs
compress-all
圧縮ルールの現在の設定を表示するには、次の例に示すように、otd_getCompressionRulePropertiesコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compression-rule-1'
otd_getCompressionRuleProperties(props)
name=compression-rule-1
condition="$uri = '^/doc'"
insert-vary-header=true
compression-level=6
fragment-size=8192
圧縮ルールを変更するには、otd_setCompressionRulePropertiesコマンドを実行します。
たとえば、次のコマンドでは、ルールcompression-rule-1の圧縮レベルがレベル8に変更されます。
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compression-rule-1'
props['compression-level'] = '8'
otd_setCompressionRuleProperties(props)
圧縮ルールを削除するには、次の例に示すように、otd_deleteCompressionRuleコマンドを実行します。
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['compression-rule'] = 'compression-rule-1'
otd_deleteCompressionRule(props)
Oracle Traffic Director仮想サーバーは、ネットワークの外側にあるクライアントが、バック・エンドにある複数のオリジン・サーバーにホストされている重要データおよびアプリケーションにアクセスする際に使用するリバース・プロキシとして機能します。この項では、リバース・プロキシ・サーバーとしてのOracle Traffic Directorのパフォーマンスを向上させるためにチューニングできるパラメータについて説明します。
キープ・アライブの有効化: このパラメータは、Oracle Traffic Director仮想サーバーがオリジン・サーバーへの永続接続を使用するか、またはリクエストごとに新規接続を作成するのかどうかを示します。これはデフォルトで有効になっています。
キープ・アライブのタイムアウト: このパラメータは、永続接続がオープンの状態で保持される最大期間(秒単位)を示します。デフォルトのタイムアウトの期間は29秒です。
アイドル・タイムアウト: このパラメータは、オリジン・サーバーへの接続がアイドル状態のまま維持される最大期間(秒単位)を示します。デフォルトの期間は300秒です。
常にキープ・アライブを使用: このパラメータは、Oracle Traffic Director仮想サーバーが、すべてのリクエスト・タイプに対して、オリジン・サーバーへの既存の永続接続を再利用できるかどうかを示します。このパラメータが有効化されていない場合(デフォルト)、Oracle Traffic Director仮想サーバーは、GET、HEADおよびOPTIONSリクエスト・メソッドについてのみ、オリジン・サーバーへの永続接続の使用を試みます。
プロキシ・バッファ・サイズ: このパラメータは、Oracle Traffic Directorがオリジン・サーバーから受信したデータをクライアントに送信する前に、そのデータを格納するバッファのサイズを示します。バッファが大きくなるほど、writeシステム・コールの数は少なくなります。プロキシ・バッファのデフォルト・サイズは、16KBです。
Oracle Traffic Director仮想サーバーとオリジン・サーバー・プール間の接続のリバース・プロキシ設定は、ルートで定義されます。リバース・プロキシ設定を変更するには、Fusion Middleware ControlまたはWLSTのいずれかを使用してルートを編集する必要があります。
注意:
現在のリリースでは、Fusion Middleware ControlまたはWLSTのいずれかを使用してプロキシ・バッファ・サイズは構成できません。
ルートのプロキシ・バッファ・サイズを構成するには、次の操作を行います。
編集するルートを含む仮想サーバーのvs_name-obj.conf構成ファイルに含まれるhttp-client-configサーバー・アプリケーション・ファンクション(SAF)にproxy-buffer-sizeパラメータを追加します。
vs_name-obj.confファイルは、次のディレクトリにあります。
INSTANCE_HOME/net-config_name/config
proxy-buffer-sizeおよびその他のリーバス・プロキシ・パラメータが構成されているルート(route1)の例を次に示します。
<Object name="route1">
ObjectType fn="http-client-config" keep-alive-timeout="31" always-use-keep-alive="true" keep-alive="false" timeout="360" proxy-buffer-size="32768"
Route fn="set-origin-server" origin-server-pool="origin-server-pool-1"
</Object>
vs_name-obj.confファイルを保存して閉じます。
pullComponentChangesコマンドを実行して、管理サーバー上の構成ストアを更新し、構成のすべてのインスタンスでこの変更を有効にします。
pullComponentChanges('otd_example.com')
otd_example.comは、プロキシ・バッファ・サイズを構成したノードの名前です。
http-client-configサーバー・アプリケーション・ファンクション(SAF)の詳細は、Oracle Traffic Director構成ファイル・リファレンスを参照してください。
Fusion Middleware Controlを使用したルートの編集
Fusion Middleware Controlを使用してルートを編集するには、次を実行します。
「Fusion Middleware Controlの表示」の説明に従って、Fusion Middleware Controlにログインします。
ページの左上隅にある「WebLogicドメイン」ボタンをクリックします。
「管理」→「OTD構成」を選択します。
使用可能な構成のリストが表示されます。
ルートを編集する構成を選択します。
「共通タスク」ペインの「Traffic Director構成」をクリックします。
「管理」→「仮想サーバー」を選択します。
「仮想サーバー」ページが表示されます。
ナビゲーション・ペインで、「仮想サーバー」を展開し、ルートを編集する仮想サーバーの名前を展開して、「ルート」を選択します。
「ルート」ページが表示されます。仮想サーバーに現在定義されているルートがリストされます。
編集するルートの「名前」をクリックします。
ルート設定ページが表示されます。
「ルート設定」ページの「詳細設定: オリジン・サーバーとの接続用のクライアント構成」セクションにある次のフィールドにreverse-proxyパラメータを指定します。
キープ・アライブ
キープ・アライブのタイムアウト
常にキープ・アライブを使用
アイドル・タイムアウト
画面上のヘルプおよびプロンプトがすべてのパラメータに提供されています。
フィールドの値を変更する、または変更したテキスト・フィールドからタブアウトすると、ページの右上隅にある「OK」ボタンが有効になります。
「取消」ボタンをクリックすることで、いつでも変更を破棄できます。
必要な変更を行った後、「OK」をクリックします。
更新された構成が保存されたことを確認するメッセージが、「コンソール・メッセージ」ペインに表示されます。
WLSTを使用したルートの構成
ルートのプロパティを変更するには、otd_setRoutePropertiesコマンドを実行します。次は、前述したリバース・プロキシ・パラメータの名前です。
keep-alive-timeout always-use-keep-alive use-keep-alive timeout
たとえば、次のコマンドでは、構成fooの仮想サーバーbar内のルートroute1のキープ・アライブ・タイムアウト時間が30秒に変更されます。
props = {}
props['configuration'] = 'foo'
props['virtual-server'] = 'bar'
props['route'] = 'route-1'
props['keep-alive-timeout'] = '30'
otd_setRouteProperties(props)
この項で説明したWLSTコマンドの詳細は、『Oracle Traffic Director WebLogic Scripting Toolコマンドライン・リファレンス』を参照してください。
この項では、Solaris固有のチューニングについて説明します。これらのプラットフォーム固有のチューニングのヒントおよび実行するすべての変更は、システム上の他のプロセスに影響を与える可能性があることに注意してください。
プラットフォームが異なると、1つのプロセスで一度に開くことができるファイル数の制限が異なります。ビジー状態のサイトでは、この数値を大きくします。Solarisシステムでは、/etc/systemファイルのrlim_fd_maxおよびrlim_fd_curを設定して、この制限を制御します。Solaris 11の場合、rlim_fd_maxのデフォルトは65536、rlim_fd_curのデフォルト値は256です。
/etc/systemファイルにこの変更またはなんらかの変更を加えた後は、新しい設定を有効にするため、Solarisを再起動します。また、Solarisを新しいバージョンにアップグレードする場合は、/etc/systemに追加したすべての行を削除し、その行がアップグレード後も有効であることを確認した後にのみ、追加しなおします。
この変更を行うもう一つの方法は、ulimit –n <value>コマンドを使用することです。このコマンドを使用する場合、システムの再起動は不要です。ただし、このコマンドはログイン・シェルを変更するのみであるのに対し、etc/systemファイルの編集はすべてのシェルに影響を与えます。
Oracle Traffic Directorインスタンスに大きな負荷がかかり、クライアントで接続タイムアウトが発生する場合は、HTTPリスナー・バックログ・キューのサイズを増やすことができます。この設定値を増やすには、HTTPリスナーのリスニング・キューの値を編集します。
これに加えて、Solaris TCP/IPネットワーキング・コード内の制限値も増やす必要があります。次のコマンドを実行して変更されるパラメータは2つあります。
ipadm set-prop -p _conn_req_max_q=4096 tcp ipadm set-prop -p _conn_req_max_q0=4096 tcp
これら2つの設定で、待機接続で満たされる可能性がある2つのSolarisリスニング・キューの最大値が増加します。設定_conn_req_max_qは、accept()コールからの戻りを待つ完了済の接続数を増やします。設定_conn_req_max_q0は、ハンドシェイクが未完了の接続の最大数を増やします。_conn_req_max_qおよび_conn_req_max_q0のデフォルト値はそれぞれ、128および1024です。
これらの変更の効果は、netstat -sコマンドを使用し、tcpListenDrop、tcpListenDropQ0およびtcpHalfOpenDropの値を見ることで監視できます。その値を確認してから、これらの値を調整します。カウンタが0でない場合は、最初に値を2048に調整し、netstatの出力の監視を継続します。
Oracle Traffic Directorで処理できる数よりも多くの接続を受け入れないでください。tcpListenDrop、tcpListenDropQ0およびtcpHalfOpenDropパラメータの値を2048に設定すると、通常は接続リクエストの失敗が減少し、4096までの値で改善効果が見られます。
HTTPリスナーのリスニング・キュー設定および、関連するSolarisの_conn_req_max_qおよび_conn_req_max_q0の設定は、Oracle Traffic Directorのスループットと一致することになります。これらのキューは、Webユーザーからの不規則な接続率を管理するバッファとして機能します。これらのキューを使用することで、Solarisでは、Oracle Traffic Directorで接続が処理されるまで、その接続を受け入れて保持できます。
TCPバッファリングは、send_bufパラメータおよびrecv_bufパラメータを使用してチューニングできます。これらのパラメータの詳細は、表17-1を参照してください。
UNIXファイル・システム(UFS)ボリュームは、各ファイルがアクセスされた時刻を保持しています。使用中の環境ではファイルのアクセス時刻の更新が重要でない場合、/etc/vfstabのデータ・ボリュームのマウント・ポイントにnoatimeパラメータを追加することにより、アクセス時刻の更新をオフにできます。次に例を示します。
/dev/dsk/c0t5d0s6 /dev/rdsk/c0t5d0s6 /data0 ufs 1 yes noatime
注意:
noatimeパラメータは、ファイルが変更されたときにはアクセス時刻の更新をオフにせず、ファイルへのアクセスがあるとオフにします。
ZFSでは、zfs setコマンドを使用して、設定可能なデータセット・プロパティを変更できます。次の例では、tank/homeのatimeプロパティをoffに設定します。
zfs set atime=off tank/home
Oracle Traffic Directorインスタンスのレスポンス時間は、ディスク・サブシステムのパフォーマンスに大きく影響されます。iostatユーティリティを使用して、ディスクのビジー状態やI/Oリクエストの完了の速さ(それぞれ%bおよびsvc_t columns)を監視できます。サービス時間は、ビジー状態が30%未満のディスクでは重要ではありません。ただし、よりビジーなディスクの場合は、サービス時間が20ミリ秒を超えないようにする必要があります。ビジーなディスクでサービスが遅い場合は、ディスク・パフォーマンスを向上させると、パフォーマンスがかなり改善する可能性があります。ビジーなディスクと負荷が少ないディスクが混在する場合は、ビジーなディスクから負荷が少ないディスクにファイルをいくつか移動して、負荷を分散します。
Solarisでは、システム動作を追跡するツールがいくつか提供されています。それらの出力をファイルに取得して後日分析することもできますが、次に示すツールは、主としてリアル・タイムにシステム動作を監視するために用意されています。
iostat -x 60コマンドは、ディスク・パフォーマンスの統計を60秒間隔でレポートします。
各ディスクのビジー状態の度合を確認するには、%b列を見ます。その時点でビジー状態が20%を超えるディスクについては、svct列でレポートされるサービス時間に注目します。その他の列は、I/O操作率、転送データ量などについての情報を示します。
vmstat 60コマンドは、仮想メモリー・アクティビティおよび一部のCPU統計を60秒間隔でまとめます。
sr列を見ると、ページ・スキャン率を追跡できます。その率が高すぎる場合には対処します。また、us列、sy列およびid列を監視して、CPUの使用率を確認します。突然爆発的に増加する処理に対応するため、多くのCPUパワーを予約しておく必要があることに注意してください。また、r列を追跡して、CPU時間で競合するスレッド数を確認します。この数がCPU数の約4倍を超えたままの場合は、サーバーの並行性を減らします。
mpstat 60コマンドはCPU統計の詳細を表示し、dlstat show-link -i 60コマンドはネットワーク・アクティビティの概要を示します。
前述のツールでシステム・パフォーマンスを監視することは重要ですが、その一方で、より長期のパフォーマンス履歴を収集することも、傾向の把握に役立つため、同様に重要です。たとえば、システムのベースライン・レコードは、システムの動作が悪くなり始めた場合に、何が変わったかのかを解明するのに役立ちます。次の手順を実行して、システム・アクティビティ・レポート・パッケージを有効化します。
次のコマンドを実行します。
svcadm enable system/sar
crontab -e sysコマンドを実行して、sa1コマンドおよびsa2コマンドを含む行からコメント文字#を削除します。サイトのアクティビティ・プロファイルに応じて、コマンドを実行する頻度および時間を調整できます。このファイルの形式の説明は、crontab manのページを参照してください。
このコマンドを使用すると、システムにより/var/adm/saディレクトリのファイルにパフォーマンス・データが保存され、デフォルトで1か月保持されます。次に、sarコマンドを使用して、目的の期間の統計を調査します。
次の表は、パフォーマンスおよびスケーラビリティのベンチマークの際に使用されるSolarisのオペレーティング・システムのチューニングを示しています。これらの値は、目的の結果を得るためのシステムのチューニング方法の例を示しています。
表17-1 パフォーマンス・ベンチマークのためのSolarisのチューニング
| パラメータ | 有効範囲 | デフォルト値 | チューニング後の値 | コメント |
|---|---|---|---|---|
|
|
256 |
65536 |
ソフト制限 |
|
|
65536 |
65536 |
プロセスのオープン・ファイル・ディスクリプタの制限。(関連するソケット、ファイルおよびパイプ(ある場合)の)予想される負荷の詳細の原因となります。 |
|
|
60000 |
600000 |
クライアントにも設定します。 |
|
|
128 |
1024 |
|
|
|
1024 |
4096 |
|
|
|
300000 |
600000 |
|
|
|
7200000 |
9000000 |
トラフィックの多いWebサイトでは、この値を低くします。 |
|
|
1000 |
3000 |
再伝送が30-40%を超える場合、この値を高くします。 |
|
|
60000 |
100000 |
|
|
|
200 |
3000 |
|
|
|
32768 |
65535 |
クライアントにも設定します。 |
|
|
49152 |
128000 |
送信バッファを増やすため。 |
|
|
128000 |
1048576 |
受信バッファを増やすため。 |
