この章には次の項が含まれます:
WebLogic Serverを起動するたびに、Javaパラメータを指定する必要があります。簡単な呼出しとしては、コマンド行にweblogic.Server
コマンドを実行して呼出しを行うことができます。ただし、コマンド行からWebLogic Serverを起動するために必要な引数は長くて、間違いやすいため、コマンドをスクリプトに組み込むことをお薦めします。この処理を簡単にするには、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic ServerインスタンスのJavaオプションの指定に関する項に記載されているように、WebLogic Server配布によって提供されたサンプル・スクリプトのデフォルト値を変更します。
構成ウィザードを使用してドメインを作成した場合、WebLogic起動スクリプトはそのドメインを指定したdomain-nameディレクトリに格納されます。このディレクトリは、デフォルトではORACLE_HOME
\user_projects\domain\
domain-name
となります。ORACLE_HOME
は、Oracle WebLogic ServerをインストールしたときにOracleホームとして指定したディレクトリ、domain-name
は、選択した構成テンプレートで定義されるドメイン・ディレクトリの名前です。
それらのスクリプトのいくつかのデフォルトJava値は、実際の環境やアプリケーションに合わせて修正する必要があります。これらのファイル内で重要なパフォーマンス・チューニング・パラメータは、JAVA_HOME
パラメータとJavaヒープ・サイズ・パラメータです。
変数JAVA_HOME
の値をJDK
の位置に変更します。例:
set JAVA_HOME=myjdk_location
ここで、myjdk_locationは、このリリースでサポートされているJDKへのパスです。Oracle Fusion Middlewareのサポートされるシステム構成を参照してください。
パフォーマンスとスループットをより高めるには、最小Javaヒープ・サイズを最大ヒープ・サイズと同じ大きさに設定します。例:
"%JAVA_HOME%\bin\java" -server –Xms512m –Xmx512m -classpath %CLASSPATH% -
ヒープ・サイズ・オプションの設定の詳細は、「ヒープ・サイズ値の指定」を参照してください。
ドメインを使用する環境として、開発環境または本番環境のどちらかを指定できます。WebLogic Serverでは、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。次の表の説明に従って、ドメインの起動モードを指定します。
表6-1起動モード
選択するモード | 条件 |
---|---|
開発 |
アプリケーションを作成する場合。このモードではセキュリティの構成がかなり緩和されるので、アプリケーションを自動デプロイできます。 |
本番 |
アプリケーションを最終的な形で実行する場合。このモードでは、セキュリティは完全に構成されます。 |
次の表に、開発起動モードと本番起動モードで異なるパフォーマンス関連の構成パラメータを示します。
表6-2 開発モードと本番モードの相違点
チューニング・パラメータ | 開発モード | 本番モード |
---|---|---|
SSL |
WebLogic Serverセキュリティ・サービスによって提供されるデモンストレーション・デジタル証明書とデモンストレーション・キーストアを使用できます。これらの証明書を使用すると、SSLで保護された環境で動作するアプリケーションを設計できます。 セキュリティ管理の詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。 |
デモンストレーション・デジタル証明書とデモンストレーション・キーストアは使用しないでください。これを行うと、警告メッセージが表示されます。 |
アプリケーションのデプロイ |
domain_name/autodeployディレクトリにあるアプリケーションをWebLogic Serverインスタンスで自動的にデプロイおよび更新できます(domain_nameはドメイン名)。 この方法は、単一サーバーの開発環境でのみ使用することを推奨します。 詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の開発ドメインでのアプリケーションの自動デプロイに関する項を参照してください。 |
自動デプロイメントの機能は無効化されているので、WebLogic Server管理コンソール、weblogic.DeployerツールまたはWebLogic Scripting Tool (WLST)を使用する必要があります。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverのデプロイメントの理解に関する項を参照してください。 |
Webサービスのテスト・クライアント |
デフォルトで有効になっています。 |
デフォルトで無効(およびアンデプロイ)になっています。『Webサービスの管理』のWebサービスのテスト・クライアントの有効化と無効化に関する項を参照してください。 |
開発から本番への起動モードの切替えについては、『Oracle WebLogic Serverサーバー環境の管理』のドメイン・モードに関する項を参照してください。
次の項では、デプロイメントのパフォーマンスを向上させる方法について説明します。
WebLogic Serverでは、起動時に、多くの内部アプリケーションがデプロイされます。この内部アプリケーションの多くは、すべてのユーザーに必要なわけではありません。これらのアプリケーションをサーバーの起動時に常にデプロイするのではなく、最初のアクセス時に(必要に応じて)待機およびデプロイするようにWebLogic Serverを構成できます。これにより、デプロイメント時のメモリーとCPU時間が節約されるとともに、サーバーの起動時間が向上しメモリー占有量が少なくなります。開発ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってオンデマンドでデプロイされます。本番モード・ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってサーバー起動時にデプロイされます。この機能を使用および構成する方法については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の内部アプリケーションのオンデマンド・デプロイメントに関する項を参照してください。
デプロイメント・モードでは、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するようWebLogic Serverを設定できます。つまり、アプリケーションが再デプロイするまで待機した後に作業していたWebページ・フローに戻るということをしないで済みます。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。
WebLogic Serverは、作業を実行するスレッドを管理するための次のメカニズムを備えています。
このリリースのWebLogic Serverでは、アプリケーションがどのような優先度で作業を実行するかを構成できます。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメント(SLA)が維持されます。
サーバー・インスタンスによるスレッドの利用方法をチューニングするには、ワーク・マネージャを定義して、WebLogic Serverドメインにグローバルに適用するか、特定のアプリケーション・コンポーネントに適用することにより、アプリケーションに対してルールや制約を定義します。主なチューニングの考慮事項は以下のとおりです。
『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。
サービス・レベル合意の(SLA)の要件は、リクエスト・クラスのインスタンスによって定義されます。リクエスト・クラスは、サーバー・インスタンスによってスレッドの割当てのために使用されるスケジューリング・ガイドラインを表します。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャの理解に関する項を参照してください。
以前のリリースの実行キューとワーク・マネージャの相違点を概念的に理解する最も簡単な方法は、実行キュー(厳密に言えば、実行キュー・マネージャ)をワーク・マネージャと関連付けて、実行キューとスレッド・プールの間の1対1の関係を切り離すことです。
WebLogic Server 9.0より前のリリースでは、着信するリクエストはデフォルトの実行キューまたはユーザー定義の実行キューに入れられます。各実行キューには実行キュー・マネージャが関連付けられています。実行キュー・マネージャは、一定数のスレッドを持つ排他的な専用のスレッド・プールを制御します。リクエストは先着順でキューに追加されます。実行キュー・マネージャは、キューから最初のリクエストを取り出し、関連付けられたスレッド・プールから使用可能なスレッドを1つ取得して、そのスレッドで実行するようにリクエストをディスパッチします。
WebLogic Server 9.0以降のリリースでは、優先度に基づいた実行キューがサーバー内に1つ用意されます。着信するリクエストには、アプリケーションが実行する作業を管理するためにユーザーが作成するワーク・マネージャの構成に基づいて、内部的な優先度が割り当てられます。サーバーでは、様々なワーク・マネージャのリクエストに応じて、実行キューで使用できるスレッドを増やしたり減らしたりします。実行キュー内のリクエストの位置は、そのリクエストの内部的な優先度によって決まります。
優先度が高いほど、実行キューの先頭近くに置かれます。
キューの先頭に近いほど、使用するスレッドに早くディスパッチされます。
ワーク・マネージャを使用すると、実行キューの場合より、スレッドの利用方法(サーバーのパフォーマンス)をうまく制御できます。その主な理由は、優先度に基づいたスレッド・プールに対してスケジューリング・ガイドラインを指定する様々な方法が用意されていることです。スケジューリング・ガイドラインは、数値として設定することも、サーバーが管理するリソース(JDBC接続プールなど)の容量として設定することもできます。
実行キューを含む以前のリリースからアプリケーション・ドメインをアップグレードすると、移行後の9.xドメインにも実行キューが含まれています。
以前のリリースからWebLogic Server 9.xにアプリケーション・ドメインを移行する場合、実行キューはワーク・マネージャに自動的に変換されません。
アップグレードされたアプリケーション構成に実行キューが存在する場合、サーバー・インスタンスは作業リクエストをdispatch-policy
で指定された実行キューに適切に割り当てます。
dispatch-policy
のないリクエストでは、自動チューニング・スレッド・プールが使用されます。
『Oracle WebLogic Serverのアップグレード』のアプリケーション環境をアップグレードするためのロードマップに関する項を参照してください。
WebLogic Serverは、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック・スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバーはスタック・スレッドを診断するたびに、メッセージのロギングを行います。
WebLogic Serverは、一定の時間にわたって継続して動作している(アイドル状態ではない)スレッドをスタックしていると診断します。スレッドがスタック・スレッドと診断されるまでの時間を変更すること、および、サーバーがスタック・スレッドを確認する頻度を変更することで、サーバーのスレッド検出動作をチューニングできます。スレッドがスタックされているかどうかを判断するためにWebLogic Serverが使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になったときに「警告」および「クリティカル」のヘルス状態を設定するデフォルトの動作は変更できません。詳細は、『Oracle WebLogic Serverサーバー環境の管理』の過負荷状態を回避するためのWebLogic Serverの構成に関する項を参照してください。スタック・スレッド検出動作を構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの実行スレッド検出動作のチューニングに関する項を参照してください。
次の項では、クライアントとサーバーの間のネットワーク通信(T3やIIOPプロトコル、およびそれらのセキュア・バージョン)に関して説明します。
WebLogic Serverは、マキサーと呼ばれるソフトウェア・モジュールを使用して、サーバーでの受信リクエストとクライアントでの受信レスポンスを読み込みます。WebLogic Serverは、次のマキサー・タイプをサポートします。
WebLogic Serverでは、非ブロッキングIOマキサー実装がデフォルトのマキサー構成として用意されています。デフォルト構成では、MuxerClass
はweblogic.socket.NIOSocketMuxer
に設定されます。
ネイティブ・マキサーは、大部分の環境ではお薦めしません。これらのマキサーを有効化する必要がある場合は、MuxerClass
属性の値を次のように明示的に設定する必要があります。
Solaris/HP-UXネイティブ・マキサー: weblogic.socket.DevPollSocketMuxer
POSIXネイティブ・マキサー: weblogic.socket.PosixSocketMuxer
Windowsネイティブ・マキサー: weblogic.socket.NTSocketMuxer
たとえば、WindowsプラットフォームでネイティブNTソケット・マキサーに切り替えると、WebLogic Serverインスタンスへのソケット接続が1つの場合に、大きなメッセージ/ペイロードに対して、パフォーマンスを向上できる可能性があります。
-Dweblogic.MuxerClass=weblogic.socket.NTSocketMux
POSIXネイティブ・マキサーは、SolarisやHP-UXなどポーリング・システム呼出しをサポートするUNIXに類似したシステムにおける大きなメッセージ/ペイロードに対して、同様のパフォーマンスの向上を提供します。
-Dweblogic.MuxerClass=weblogic.socket.PosixSocketMuxer
一方、ネイティブ・マルチプレクサは、プラットフォーム固有のネイティブ・バイナリを使用して、ソケットからデータを読み込みます。大多数のプラットフォームには、データに関してソケットをポーリングする何らかのメカニズムがあります。たとえば、UNIXシステムではポーリング・システム呼出しが使用され、Windowsアーキテクチャでは完了ポートが使用されます。ネイティブ・マキサーは非ブロッキング・スレッド・モデルを実装します。ネイティブ・マルチプレクサが使用されると、サーバーでは受信リクエストの読取り専用の固定数のスレッドが作成されます。WebLogic Server 12.1.2以前では、ネイティブ・マキサーを使用してパフォーマンス・パックとして参照することをお薦めしていました。
WebLogic Server 12.1.2およびそれ以降のリリースでは、非ブロッキングIO (NIO)マキサーはデフォルトではお薦めしません。ただし、リリース12.1.2以前のWebLogic Serverをアップグレードするユーザーが、アップグレード後のランタイム環境の整合性を最大限に保てるよう、今でもネイティブ・マキサーはオプションとして提供しています。Oracle WebLogic Server管理コンソール・ヘルプのネイティブIOの有効化に関する項を参照してください。
ネイティブ・マキサーでは、次の設定を使用すると、CPUにバインドされたアプリケーションのスループットを向上できる場合があります。
-Dweblogic.socket.SocketMuxer.DELAY_POLL_WAKEUP=xx
xxは、データが使用可能かどうかをチェックする前に遅延する時間です(マイクロ秒単位)。デフォルト値は0で、遅延なしに相当します。
ネイティブ・マキサーは、大部分の環境ではお薦めしません。これらのマキサーを有効化する必要がある場合は、MuxerClass
属性の値を次のように明示的に設定する必要があります。
Solaris/HP-UXネイティブ・マキサー: weblogic.socket.DevPollSocketMuxer
POSIXネイティブ・マキサー: weblogic.socket.PosixSocketMuxer
Windowsネイティブ・マキサー: weblogic.socket.NTSocketMuxer
たとえば、WindowsプラットフォームでネイティブNTソケット・マキサーに切り替えると、WebLogic Serverインスタンスへのソケット接続が1つの場合に、大きなメッセージ/ペイロードに対して、パフォーマンスを向上できる可能性があります。
-Dweblogic.MuxerClass=weblogic.socket.NTSocketMux
POSIXネイティブ・マキサーは、SolarisやHP-UXなどポーリング・システム呼出しをサポートするUNIXに類似したシステムにおける大きなメッセージ/ペイロードに対して、同様のパフォーマンスの向上を提供します。
-Dweblogic.MuxerClass=weblogic.socket.PosixSocketMuxer
一方、ネイティブ・マルチプレクサは、プラットフォーム固有のネイティブ・バイナリを使用して、ソケットからデータを読み込みます。大多数のプラットフォームには、データに関してソケットをポーリングする何らかのメカニズムがあります。たとえば、UNIXシステムではポーリング・システム呼出しが使用され、Windowsアーキテクチャでは完了ポートが使用されます。ネイティブ・マキサーは非ブロッキング・スレッド・モデルを実装します。ネイティブ・マルチプレクサが使用されると、サーバーでは受信リクエストの読取り専用の固定数のスレッドが作成されます。WebLogic Server 12.1.2以前では、ネイティブ・マキサーを使用してパフォーマンス・パックとして参照することをお薦めしていました。
WebLogic Server 12.1.2およびそれ以降のリリースでは、非ブロッキングIO (NIO)マキサーはデフォルトではお薦めしません。ただし、リリース12.1.2以前のWebLogic Serverをアップグレードするユーザーが、アップグレード後のランタイム環境の整合性を最大限に保てるよう、今でもネイティブ・マキサーはオプションとして提供しています。Oracle WebLogic Server管理コンソール・ヘルプのネイティブIOの有効化に関する項を参照してください。
ネイティブ・マキサーでは、次の設定を使用すると、CPUにバインドされたアプリケーションのスループットを向上できる場合があります。
-Dweblogic.socket.SocketMuxer.DELAY_POLL_WAKEUP=xx
xxは、データが使用可能かどうかをチェックする前に遅延する時間です(マイクロ秒単位)。デフォルト値は0で、遅延なしに相当します。
Javaマキサーには次の特徴があります。
ソケットからのデータの読込みにpure-Javaが使用されます。
RMIクライアントで利用可能な唯一のマキサー。
ソケットから読み込まれるデータが現れるまで読込みはブロックされます。この動作は、ソケットが大量に存在する場合や、ソケットにデータが到達する頻度が低い場合は、あまり効率がよくありません。これは、クライアントでは通常問題になりませんが、サーバーで大きなボトルネックになる場合があります。
これらの特徴は、クライアントの数が少なく、サーバーに届く要求のレートが非常に高いときに受諾できる場合があります。これらの条件下では、Java Muxerはネイティブ・マキサーと同様のパフォーマンスを発揮し、Javaネイティブ・インタフェース(JNI)のオーバーヘッドが解消されます。ネイティブ・マキサーと異なり、Java Muxerでは、リクエストの読込みに使用されるスレッドの数は固定されず、WebLogic Server管理コンソールのPercent Socket Readers
パラメータ設定を構成することで調整できます。理想的には、スレッドの数がリモートの同時に接続されたクライアントの数とほぼ同じ(最高でも合計スレッド・プール・サイズの50%まで)となるようにこのパラメータを構成する必要があります。各スレッドは、ソケットでデータが利用できるようになるまで一定の時間だけ待機します。到着するデータがない場合、スレッドは次のソケットに移動します。
ネットワーク・チャネル(ネットワーク・アクセス・ポイントとも呼ばれる)では、ネットワーク通信の様々なサービス品質(QOS)パラメータを指定できます。各ネットワーク・チャネルは、固有IPアドレスおよびポートを使用して、排他的な独自のソケットに関連付けられます。デフォルトでは、マルチスレッド・クライアントからのT3リクエストが同じリモート接続に対して多重化され、サーバー・インスタンスがソケットからのリクエストを1つずつ読み込みます。リクエストのサイズが大きい場合、これがボトルネックになります。
ネットワーク・チャネルの主な役割はサーバー・インスタンスのネットワーク・トラフィックを制御することですが、複数のカスタム・チャネルを作成できる機能を利用すると、マルチスレッド・クライアントが、複数の接続に対してサーバー・インスタンスと通信でき、ボトルネックの危険性が軽減されます。カスタム・マルチチャネル通信を構成するには、次の手順に従います。
『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。
WebLogic Serverでは、システムの可用性を最適化すると同時にサービス妨害(DoS)攻撃の可能性を低減するために次の設定を指定することができます。
受信メッセージの最大サイズ
完了メッセージ・タイムアウト
ファイル記述子数(UNIXシステム)
システムのパフォーマンスを最大限にするために、次の項に記載されているように、WebLogic Serverをホストする特定のシステムでこれらの設定が適切で、お互いにバランスが取れてる必要があります。
WebLogic Serverを使用すると、一連の大きなリクエストが攻撃に遭わないように受信リクエスト最大のサイズを指定できます。別々のプロトコルとネットワーク・チャネルに対してグローバルの値または特定の値を設定できます。パフォーマンスには直接的に影響しませんが、宛先へ送信する前にJMSアプリケーションに収集されたメッセージのサイズが指定した値より大きい場合、そのJMSアプリケーションは拒否される場合があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: プロトコル: 一般に関する項、および「順序単位を使用したアプリケーションのチューニング」を参照してください。
「完了メッセージ・タイムアウト」パラメータがシステムで正しく構成されていることを確認します。このパラメータを使用すると、サーバーが完了メッセージを受信するまでに待機する最大秒数を設定できます。
デフォルト値は60秒で、デフォルト・ネットワーク・チャネルのすべての接続プロトコルに適用されます。サーバーに待機時間の長いクライアントが多くある場合、この設定が適切である場合があります。ただし、システムの可用性を侵害することなく、この設定を可能なかぎり小さな値にする必要があります。
特定のプロトコルのために完了メッセージ・タイムアウトを指定する必要がある場合、かわりに、そのプロトコルに対して新しいネットワーク・チャネルを構成できます。
完了メッセージ・タイムアウト・パラメータを指定できる「WebLogic Server管理コンソール」ページの表示の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのプロトコルの構成に関する項を参照してください。
UNIXシステムでは、WebLogic Serverへの各ソケット接続がファイル記述子を消費します。可用性を最適化するには、ホスト・マシン上のWebLogic Serverのファイル記述子数が適切である必要があります。デフォルトでは、WebLogic Serverには、1024個ファイル記述子数が構成されています。ただし、特に本番システムでは、この値は小さく設定される場合があります。
WebLogic Serverのファイル記述子数をチューニングする場合、ファイル記述子に行った変更は「完了メッセージ・タイムアウト」パラメータに行った変更とバランスが取れている必要があります。「完了メッセージ・タイムアウト」パラメータの値が大きい場合、メッセージ・タイムアウトが発生するまでソケットが閉じられません。これにより、ファイル記述子の保留時間が長くなります。したがって、「完了メッセージ・タイムアウト」パラメータの値が大きい場合、ファイル記述子数の制限も大きく設定する必要があります。これにより、システムの可用性が最適化され、サービス妨害攻撃の可能性を低減できます。
使用可能なファイル記述子数のチューニング方法については、UNIXベンダーのドキュメントを参照してください。
追加のリクエストを拒否する前にWebLogic Serverのインスタンスが受け取る接続リクエスト数をチューニングできます。「バックログの受入れ」
パラメータは、待機キューにバッファできるTransmission Control Protocol (TCP)接続数を指定します。この固定サイズ・キューは、TCPスタックで受信し、アプリケーションではまだ受け取られていない接続リクエストに追加されます。
WebLogic Serverのインスタンスで追加のリクエストを否定する前に、受け取る接続リクエスト数をチューニングできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続バックログ・バッファのチューニングに関する項を参照してください。
HTTP 1.1プロトコルでキープ・アライブが有効な場合に、キャッシュからソケット接続を返す動作のチューニング用のhttp.keepAliveCache.socketHealthCheckTimeout
システム・プロパティを使用します。デフォルトでは、キャッシュされた接続がクライアントに返され使用できるようになるまで、キャッシュはヘルス状態をチェックしません。ネットワーク接続が不安定な場合などの一定の条件では、クライアントに返す前にシステムが接続ヘルス状態をチェックする必要があります。この動作(ヘルス状態のチェック)を有効にするには、http.keepAliveCache.socketHealthCheckTimeout
を0より大きい値に設定します。
多数のコアを持つシステムの重い負荷で複数のパーティションを実行している場合、CPU使用率を向上するためにWLSスレッド・プールの設定をいくつか変更する必要がある場合があります。スレッド・プールのチューニングはスループットを向上し、レスポンス時間を削減し、CPU使用率を向上します。
次のガイドラインを開始点として考慮する必要があります。特定のワークロードの最適設定を見つけるためには、様々な値を試みる必要があります。
マルチプレクサ・スレッド(ソケット・リーダー)
マルチプレクサ・スレッドには、受信するネットワーク・リクエストを処理し、それを適切なワーク・スレッドにディスパッチする役割があります。ネイティブ・マルチプレクサ(通常、デフォルト・マルチプレクサ)では、WLSはかなり少ない(4つの)マルチプレクサ・スレッドを使用しますが、この値はコアの高いカウント・システムのスループット容量を保つには十分ではありません。
WLSサーバーでマルチプレクサ・スレッドの数を増やす方法は次のとおりです。
ServerMBean.setSocketReaders(N)
を使用して設定するか、
サーバーの起動時に次のJAVA_OPTIONを渡して設定します: -Dweblogic.SocketReaders=N
ソケット・リーダーの数を確認するには、サーバーの起動時にログ・メッセージ: Allocating N reader threads
を参照します。
はじめに、マルチプレクサ・スレッドの数をシステム・ハードウェア・スレッドの数のおよそ20%になるように設定してみます。
スレッド・プール
スレッド・プールは、マルチプレクサ・スレッドによってリクエストがディスパッチされた後、WLSで作業するようにスレッドを割り当てる役割を持ちます。デフォルトでは、WLSは自動チューニング・プールを使用し、これは一般的に様々なワークロードで良好に動作しますが、一定の高負荷の環境では、スレッド・プール・サイズをチューニングしてサーバーのコアの数と適合させた方が効率的な場合があります。
WLSサーバーでスレッド・プール設定を変更する手順は次のとおりです。
ServerMBean.setSelfTuningThreadPoolSizeMin(N)
およびsetSelfTuningThreadPoolSizeMax(N)
を使用して設定するか、
サーバーの起動時に次のJAVA_OPTIONを渡して設定します: -Dweblogic.threadpool.MinPoolSize=N -Dweblogic.threadpool.MaxPoolSize=N
はじめに、スレッド・プールの最小サイズと最大サイズをシステム・ハードウェア・スレッドの数のおよそ80%になるように設定してみます。
様々な数のパーティションに対してリソース消費管理(RCM)が有効な場合、パフォーマンスを向上させるために、WLSではシステム・プロパティweblogic.work.rcm.perPartitionPoolSize
が導入され、各パーティション・プール・サイズをチューニングできます。
RCMが有効な場合、WLS自己チューニング・スレッド・プールは、以前にパーティションで作業リクエストを実行したスレッドを使用して、同一のパーティションで次の作業リクエストを実行します。WLSでは、各パーティションのスレッドのキャッシュが保持されます。このキャッシュのデフォルト・サイズは、16スレッドです。weblogic.work.rcm.perPartitionPoolSize
システム・プロパティを使用して、キャッシュ・サイズを構成できます。指定する場合、1から256の間の値に指定し、これは最も近い2の倍数に切り捨てられます。値が小さいとメモリー使用量が減少し、大きい値は作業リクエストを実行するためのキャッシュ済スレッドを同一パーティションから検出できるチャンスが高くなります。
リソース共有のトピックに関する詳細は、『WebLogic Server MTの使用』のリソース消費管理の構成に関する項を参照してください。
optimize-java-expression要素を設定すると、Java式を最適化して実行時パフォーマンスを向上させることができます。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のjsp-descriptorに関する項
を参照してください。
WebLogic ServerクラスタはWebLogic Serverインスタンスのグループで、互いに連携してフェイルオーバーおよびレプリケーション・サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバーに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバー群です。
ドメインには複数のWebLogic Serverクラスタと、クラスタリングされないWebLogic Serverインスタンスが存在できます。ドメイン内でクラスタリングされるWebLogic Serverインスタンスの動作は、フェイルオーバーとロード・バランシングの機能を備えること以外は、クラスタリングされないインスタンスと同様です。インスタンスのすべての構成パラメータは、そのインスタンスがクラスタリングされるかどうかにかかわらず、そのドメインの管理サーバーによって管理されます。
クラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverクラスタの理解に関する項を参照してください。
スケーラビリティとは、リソースの追加に伴ってシステムが1つまたは複数の側面において拡張していく能力です。通常、これらの側面としては(他にも多数ありますが)サポート可能な同時接続ユーザーの数や、一定時間に処理可能なトランザクションの数などが挙げられます。
優れたアプリケーションであれば、単にリソースを追加することによってパフォーマンスが向上します。WebLogic Serverの負荷処理の機能を強化するには、新しいWebLogic Serverインスタンスをクラスタに追加します。その際、アプリケーションを変更する必要はありません。クラスタは、単一のサーバーでは提供できない、スケーラビリティと可用性という2つの大きなメリットをもたらします。
WebLogic Serverクラスタは、アプリケーション開発者からは見えないように、Java EEアプリケーションにスケーラビリティと高可用性を提供します。スケーラビリティにより中間層の能力が拡張され、単一のWebLogic Serverまたはコンピュータの能力を超過することができます。クラスタ・メンバーシップの唯一の制限は、すべてのWebLogic ServerがIPマルチキャストで通信できなければならないということです。新しいWebLogic Serverをクラスタに動的に追加して能力を増大させることもできます。
WebLogic Serverクラスタは、複数サーバーの冗長性を利用してクライアントを障害から保護することで高可用性を確保します。クラスタ内の複数のサーバーで、同じサービスを提供できます。1つのサーバーで障害が発生しても、別のサーバーが引き継ぎます。障害が発生したサーバーから機能しているサーバーへのフェイルオーバー機能によって、クライアントに対するアプリケーションの可用性が増大します。
注意:
すべてのアプリケーションおよび環境上のボトルネックが解決済という条件下で初めて、クラスタへの新しいサーバーの追加により、直線的なスケーラビリティが実現されます。ベンチマークまたは初期構成テストを実行するときには、単一サーバー環境における問題を洗い出した後で、クラスタリングされた環境に移行してください。
メッセージング・サービスでのクラスタ化は、分散宛先、接続のコンセントレータ、接続のロード・バランシング(接続ファクトリのターゲット指定によって決定されます)、およびクラスタリング・ストア・アンド・フォワード(SAF)を介して提供されます。分散宛先に関するクライアントのロード・バランシングは、接続ファクトリで調整できます。分散宛先をホストする同じクラスタにターゲット指定されている分散宛先のメッセージドリブンBean (MDB)は、分散宛先のメンバーをホストするクラスタ・サーバーでのみ自動的にデプロイし、それらのローカル宛先からのメッセージのみ処理します。分散宛先のホストとは異なるサーバーまたはクラスタにターゲット指定されている分散キューMDBは、各分散宛先メンバーに対してコンシューマを自動的に作成します。たとえば、実行中の各MDBは、各分散宛先キュー・メンバーに対して1つのコンシューマを持ちます。
一般的に、クラスタ内のサーバー間で通信を必要とする処理は、スケーラビリティの潜在的な障害となります。次の項では、クラスタリングWebLogicサーバーを直線的にスケーリングする際に影響のある問題について説明します。
WebLogicサーバーのクラスタがスケーリングに失敗する多くの状況では、データベースがボトルネックとなっています。こうした状況における唯一のソリューションとして、データベースをチューニングするか、他のオプションを調査してデータベース上の負荷を軽減します。「データベースのチューニング」および「データ・ソースのチューニング」を参照してください。
ユーザー・セッション・データは、2つの標準的な方法(ステートフル・セッションEJBまたはHTTPセッション)で、Java EEアプリケーションに格納できます。これらだけで、クラスタのスケーラビリティが影響されることはほとんどありません。ただし、高可用性を提供するために必要なセッション・レプリケーション・メカニズムと組み合わされると、ボトルネックが発生します。Java EEアプリケーションにWebおよびEJBコンポーネントがある場合、次の理由から、ユーザー・セッション・データはHTTPセッションに格納する必要があります。
HTTPセッション管理では、レプリケーション、共有DBまたは共有ファイルなど、フェイルオーバーを処理するためのオプションが多数提供されます。
スケーラビリティが優れています。
HTTPセッションの状態のレプリケーションは、すべてのトランザクションの外部で発生します。一方、ステートフル・セッションBeanのレプリケーションは、よりリソースが消費されるトランザクション内部で発生します。
HTTPセッションのレプリケーション・メカニズムは高度に洗練され、ステートフル・セッションBeanのレプリケーションよりも広範な状況で最適化を実現します。
「セッション管理」を参照してください。
HTTPセッションの非同期レプリケーションでは、以下を使用する非同期セッション・レプリケーションを選択できます。
PersistentStoreTypeをasync-replicatedまたはasync-replicated-if-clusteredに設定して、プライマリ・サーバーとセカンダリ・サーバー間でのデータの非同期レプリケーションを指定します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThresholdパラメータを調整します。
レプリケーションの動作は、クラスタのタイプによって異なります。次の表では、特定のクラスタ・トポロジでの非同期レプリケーションの動作について説明します。
表6-3 クラスタ・トポロジでの非同期レプリケーションの動作
トポロジ | 動作 |
---|---|
LAN |
同一クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。 |
MAN |
リモートのクラスタのセカンダリ・サーバーにレプリケートされます。これは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。 |
WAN |
クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。リモートのクラスタを介するデータベースの永続性は、「async-replication」と「replication」のどちらが選択されていても非同期的に発生します。 |
次に、非同期レプリケーション・セッションの動作の概要を示します。
アンデプロイメント時または再デプロイメント時は、次のように動作します。
セッションが登録解除され、更新キューから削除されます。
セカンダリ・サーバー上のセッションが登録解除されます。
アプリケーションが管理モードに移行している場合、セッションはフラッシュされてセカンダリ・サーバーへレプリケートされます。セカンダリ・サーバーが停止している場合は、システムは別のサーバーへのフェイルオーバーを試みます。
セッション情報の消失の可能性を最小限に抑えるため、サーバーが停止したり障害が発生したりするとバッチ処理されたセッションのレプリケーションが発生します。
PersistentStoreTypeをasync-jdbcに設定して、データのデータベースへの非同期レプリケーションを指定します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThresholdパラメータおよびSessionFlushIntervalパラメータを調整します。
次に、非同期レプリケーション・セッションの動作の概要を示します。
アンデプロイメント時または再デプロイメント時は、次のように動作します。
セッションが登録解除され、更新キューから削除されます。
セッションがデータベースから削除されます。
アプリケーションが管理モードに移行している場合、セッションはフラッシュされてデータベースへレプリケートされます。
これは、読み書きパターン付きReadOnly
またはOptimistic
の並行性戦略を使用するエンティティEJBに適用されます。
Optimistic
- Optimistic
並行性が更新されると、EJBコンテナはマルチキャスト・メッセージを他のクラスタ・メンバーに送信し、それらのBeanのローカル・コピーを無効化します。これは、オプティミスティックな並行性の例外が他のサーバーによってスローされるのを防ぐ(それによってトランザクションを再試行する必要性を回避する)ために行われます。EJBに対する更新が頻繁に行われる場合、お互いのローカル・キャッシュを無効化するためにサーバーによって行われる処理が、重大なボトルネックになります。こうした無効化をオフにするには、cluster-invalidation-disabled
と呼ばれるフラグ(デフォルトはfalse)を使用します。これは、rdbms
記述子ファイルで設定します。
読み書きパターン付きReadOnly
- このパターンでは、これを使用しなければ単一EJBで表現される永続データが、実際に2つのEJB(読取り専用と更新可能)で表現されます。更新可能Beanの状態が変更されると、コンテナは対応する読取り専用EJBインスタンスを自動的に無効化します。EJBに対する更新が頻繁に行われる場合、読取り専用EJBを無効化するためにサーバーによって行われる処理が、重大なボトル・ネックになります。
「エンティティEJBの無効化」と同様、HTTPセッションも無効化できます。これについては、無効化する必要があるのはセカンダリ・サーバーに格納されているセッション・データのみなので、エンティティEJBの無効化ほどコストがかかりません。HTTPセッションがもう使用されていない場合、無効化する必要があります。
マルチ・コア・マシンについては、クラスタリングされたWebLogic Serverインスタンスと使用可能なコア数の比率を考慮する必要があります。WebLogic Serverには、クラスタ内のサーバー・インスタンス数の制限が組み込まれていないため、大規模なマルチ・コア・サーバーでは、非常に大規模なクラスタまたは多くのクラスタをホストする可能性があります。
WebLogic Serverインスタンスに対するコアの最適な比率を決定するときに次の事項を考慮してください。
アプリケーションのメモリー要件。個別インスタンスのヒープ・サイズとインスタンスの総合数を選択して、アプリケーションに十分なメモリーが提供されていて、よいガベージ・コレクション(GC)パフォーマンスが達成できることを確認します。いくつかのアプリケーションでは、単一のインスタンスに非常に大きなヒープ・サイズを割り当てると、ガベージ・コレクション(GC)の休止時間が長くなる場合があります。この場合は、インスタンス数を増加し、各インスタンスに小さいヒープを割り当てると、パフォーマンスが向上する場合があります。
CPUの最大使用。WebLogic Serverでは、インスタンスごとに複数のコアを使用できるので、いくつかのアプリケーションにおいて指定したマシン上のインスタンス数を増加(インスタンスごとにコア数の減少)すると、CPUの使用とパフォーマンスを向上できます。
XAトランザクション・クラスタ・アフィニティによって、グローバル・トランザクションに参加しているサーバー・インスタンスが、関連するリクエストを他のメンバー・サーバーにロード・バランシングしないで処理できるようになります。Enable Transaction Affinity=true
の場合、クラスタ・スループットは次のようにすることによって増加します。
サーバー間トランザクション調整トラフィックの削減
JDBC接続の削減など、リソース使用率の向上
トランザクションの非同期処理の単純化
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの構成に関する項および『Oracle WebLogic Serverクラスタの管理』のXAトランザクション・アフィニティに関する項を参照してください。
次の項では、WebLogic Serverドメインのモニター方法を説明します。
管理コンソールは、WebLogic Serverドメインのヘルス状態とパフォーマンスをモニターするツールです。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの監視に関する項を参照してください。
WebLogic診断フレームワーク(WLDF)は、監視および診断フレームワークであり、WebLogic Serverのプロセス内で実行する一連のサービスの定義および実装を行い、標準サーバー・ライフ・サイクルに参加します。『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDFアーキテクチャの概要に関する項を参照してください。
WebLogic Serverでは、独自の一連のMBeansが提供されています。これらを使用して、WebLogic Serverリソースを構成、モニターおよび管理することができます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。
WebLogic Scripting Tool (WLST)はコマンドライン・スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。
Oracle Technology Network (http://www.oracle.com/technetwork/index.html
)では、製品のダウンロード、記事、サンプル・コード、製品ドキュメント、チュートリアル、ホワイト・ペーパー、ニュース・グループ、およびWebLogic Serverのその他の主要なコンテンツを提供しています。
WebLogic Serverにおけるデフォルトのクラスおよびリソースのロードでは、デフォルトでクラスローダーの階層がルートから検索されます。その結果、クラスまたはリソースがアプリケーションに属している場合でも、クラスまたはリソースのロードが要求されるたびにシステム・クラスパス
全体が検索されます。一度だけルックアップされるクラスやリソース(デプロイメント時のクラスロードなど)の場合は、classpath
全体の検索にかかる負荷が重大な問題となることは通常はありません。実行時にアプリケーションによって繰返し要求されるクラスやリソース(loadClass
またはgetResource
の明示的な呼出し)の場合は、システムやアプリケーションの長いclasspath
が繰り返し検索されることでCPUやメモリーのオーバーヘッドが増大する可能性があります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。クラスまたはリソースが見つからない場合はclasspath
の全体スキャンの負荷が発生し、アプリケーションがクラス/リソースの検索に失敗するとリクエストが繰り返される可能性があるため、さらに負荷が高まります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。
見つからないクラスまたはリソースのリクエストおよび同じクラス/リソースをロードするために頻繁に繰り返される呼出しは回避されるよう、アプリケーション・コードが最適化されているのが理想です。サード・パーティのライブラリなど、アプリケーション・コードの修正が可能でない場合は、WebLogic Serverの「フィルタリング・ローダー・メカニズム」を使用します。
WebLogic Serverでは、フィルタリング・ローダー・メカニズムが用意されており、これによって、アプリケーション・クラスパス
にある特定のアプリケーション・クラスとリソースを検索するときにシステム・クラスパス
の検索を省略できます。このメカニズムでは、ユーザーはシステム・クラスパス
の検索を省略する特定のクラスとリソースを指定する必要があります。『Oracle WebLogic Serverアプリケーションの開発』のフィルタリング・クラスローダーの使用に関する項を参照してください。
このリリースでは、リソースをロードするリクエストをフィルタリングできる機能が追加されました。リソース・フィルタリングの基本的な構成は、META-INF/weblogic-application.xml
ファイルで指定します。クラス・フィルタリングの場合も同様です。リソースをフィルタリングする構文の例を以下に示します。
<prefer-application-resources> <resource-name>x/y</resource-name> <resource-name>z*</resource-name> </prefer-application-resources>
この例では、「x/y」という名前のリソースと「z」で名前が始まるリソースにリソース・フィルタリングが構成されています。使用できるワイルド・カードのパターンは「*」のみです。これらのパターンに一致する名前を持つリソースはアプリケーション・クラスパス
上でのみ検索され、システム・クラスパス
の検索はスキップされます。
注意:
フィルタリング構成にクラスまたはリソースを追加した後で、クラスまたはリソースが見つからないことを示す例外が発生した場合は、クラスまたはリソースがアプリケーション・クラスパス
上ではなくシステム・クラスパス
上に存在している可能性があります。
WebLogic Serverは、起動を高速化するためにクラス・キャッシングを有効にできます。キャッシングを有効にすると、サーバーは特定の基準に達するまでロードされるすべてのクラスを記録し、クラス定義を非表示のファイルに保持します。サーバーを再起動すると、キャッシュの有効性が既存のコード・ソースによりチェックされます。そして、サーバーは実行回数に記録されたクラスと同じ一連のクラスをバルク・ロードするためキャッシュ・ファイルを使用します。システム・クラスパスまたはその内容を変更すると、キャッシュは無効になり、サーバー再起動時に再作成されます。
クラス・キャッシングを使用する利点は次のとおりです。
サーバーの起動時間が短縮されます。
パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。
詳細は、『Oracle WebLogic Serverアプリケーションの開発』のクラス・キャッシュの構成に関する項を参照してください。
注意:
startWebLogic
スクリプトを使用することで、クラス・キャッシュはサーバーの起動時に開発モードでサポートされます。デフォルトでは、クラス・キャッシングは無効になっており本番モードではサポートされません。開始時間の短縮はJREベンダーによって異なります。