WebLogic Server パフォーマンス チューニング ガイド
|
 |
 |
|
以下の節では、ハードウェア、オペレーティング システム、およびネットワーク パフォーマンスの最適化に関する考慮事項について説明します。
パフォーマンスを調べる場合、所定のハードウェア コンフィグレーションで WebLogic Server と所定のアプリケーションをサポートするために必要な処理能力にはさまざまな要因が影響します。個々のアプリケーションおよびコンフィグレーションによって、アプリケーションをサポートするために必要なハードウェアの処理能力が異なります。それぞれの要因を、どのように各アプリケーションおよびコンフィグレーションに適用するかを検討する必要があります。実際にハードウェアをチューニングする前に、以下を参照してハードウェア コンフィグレーションのプランニングについて検討してください。
次の表に、『サポート対象のコンフィグレーション』の該当箇所へのリンクを示します。WebLogic Server の各リリースでサポートされているハードウェアおよびオペレーティング システム プラットフォームの最新の動作確認情報が入手できます。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
オペレーティング システムのチューニングは、使用しているオペレーティング システムのマニュアルに従って行ってください。BEA では、『サポート対象のコンフィグレーション』に示す複数のオペレーティング システム上で WebLogic Server の動作確認をしています。
Windows プラットフォームの場合、通常はデフォルト設定を変更する必要はありません。一方、Solaris および Linux プラットフォームでは、通常は適切なチューニングを行う必要があります。
以下の節では、Solaris オペレーティング システムのチューニングに関する情報を示します。
次の例に従い、nddコマンドを使用して以下の TCP 関連のチューニング パラメータを設定します。
ndd -set/dev/tcp tcp_conn_req_max_q 16384
注意 : Solaris 2.7 以前では、tcp_time_wait_interval パラメータを tcp_close_wait_interval と呼んでいました。このパラメータには、close の呼び出しを発行した後に TCP ソケットを生存させる時間間隔を指定します。Solaris の場合、このパラメータのデフォルト値は 4 分となります。短時間に数多くのクライアントが接続する場合、これらのソケット リソースを保持するとパフォーマンスに大きな悪影響を及ぼします。Solaris でのベンチマーク JSP テストでは、このパラメータの値を 60000 (60 秒) に設定するとスループットがかなり改善するという結果が出ています。オープン途中の接続のキューでサーバがバックアップされている場合は、この値をもっと減らすことも可能です。
ヒント : 使用できる TCP パラメータをすべて表示するには、netstat -s -P tcp コマンドを使用します。
サーバへの各ソケット接続ではファイル記述子を消費します。ソケットのパフォーマンスを最適化するには、オペレーティング システムをコンフィグレーションして適切な数のファイル記述子を用意しておく必要があります。したがって、/etc/system ファイル内にあるチューニング パラメータ (ファイル記述子の最大数、ハッシュ テーブルのサイズなど) を、デフォルト値から次の表に示す推奨値に変更してください。
注意 : /etc/system パラメータを変更したら、マシンを再起動する必要があります。
CE Gigabit カードを使用する場合は、以下の設定を使用することをお勧めします。
Solaris のチューニング オプションの詳細については、以下を参照してください。
Linux オペレーティング システムで最適なパフォーマンスを実現するには、以下のように設定することをお勧めします。
Linux のチューニングの詳細については、Linux ベンダのマニュアルを参照してください。また、「Ipsysctl Tutorial 1.0.4」では、Linux で提供されるすべての IP オプションについて説明されています。
HP-UX オペレーティング システムで最適なパフォーマンスを実現するには、以下のような TCP 設定をお勧めします。
HP-UX のチューニング情報については、「Tunable Kernel Parameters」リファレンス ドキュメントを参照してください。
Windows、HP-UX、および AIX のチューニング オプションの詳細については、以下の Web サイトを参照してください。
ネットワークのパフォーマンスが低下するのは、リソースの供給が需要に追いつくことができない場合です。最近のエンタープライズ レベルのネットワークは非常に高速で、適切に設計されたアプリケーションであれば、パフォーマンス低下の直接的な原因になることはまれです。しかし、1 つまたは複数のネットワーク コンポーネント (ハードウェアまたはソフトウェア) に問題が見つかった場合は、ネットワーク管理者と協力してその問題を洗い出し、解決する必要があります。WebLogic Server 用に、適切な広さのネットワーク帯域幅、およびアーキテクチャ内の他の層への適切な数の接続 (クライアント接続やデータベース接続など) が用意されているかどうかを検証する必要もあります。したがって、パフォーマンスの潜在的なボトルネックを解消するには、ネットワークのパフォーマンスを継続的にモニタすることが重要です。
帯域幅は、一般には「データ通信の転送レート、通常は通信を送受信するためのリンクを容量を bps (bits-per-second) で表したもの」と定義されます。WebLogic Server を実行するマシンには、そのすべての WebLogic Server クライアント接続を処理できるだけの十分な帯域幅が必要です。プログラムに基づくクライアントの場合、クライアント JVM ごとにサーバへの 1 つのソケットがあり、ソケットごとに専用の帯域幅が必要になります。WebLogic Server インスタンスでプログラムに基づくクライアントを処理するには、同様な Web サーバで処理する場合の 125 ～ 150% の帯域幅が必要になります。HTTP クライアントのみを処理する場合は、静的ページを提供する Web サーバと同程度の帯域幅が必要になると考えてください。
所定のデプロイメントに十分な帯域幅があるかどうかを調べるには、使用しているネットワーク オペレーティング システムのベンダから提供されているネットワーク モニタ ツールを使用して、ネットワーク システム上の負荷を参照します。ネットワークの利用状況は、Solaris の netstat コマンド、Windows のシステム モニタ (perfmon) など、一般的なオペレーティング システム ツールを使用してモニタすることもできます。負荷が非常に高い場合は、帯域幅がシステムの問題点になっている可能性があります。
また、アプリケーションとアプリケーション サーバの間およびアプリケーション サーバとデータベース サーバの間で転送されているデータをチェックして、ネットワーク上で転送されるデータの量をモニタします。このデータ量がネットワークの帯域幅を超えないようにします。帯域幅を超える場合、ネットワークがボトルネックとなります。 これを確認するには、次のコマンドを使用して、パケットの再転送や重複に関するネットワーク統計値をモニタします。
netstat -s -P コマンドを使用してその他の TCP パラメータを表示する手順については、「ndd コマンドを使用した TCP パラメータの設定」を参照してください。
ローカル エリア ネットワークには、アプリケーションのピーク容量を処理できるだけの速度が必要になります。ネットワークがフルに使用されていると、トラフィックの量が常に帯域幅の容量を超える状態となり、WebLogic Server マシンを有効に活用できなくなります。この場合は以下のように対処してください。
|
|
|