5 WebLogic Serverのチューニング
- WebLogic Serverを起動するためのJavaパラメータの設定
WebLogic Serverを起動するたびに、Javaパラメータを指定する必要があります。 - 開発モードと本番モードのデフォルトのチューニング値
ドメインを使用する環境として、開発環境または本番環境のどちらかを指定できます。WebLogic Serverでは、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。 - デプロイメント
デプロイメント・パフォーマンスを向上させるための手法を学習します。 - スレッド管理
WebLogic Serverは、作業を実行するスレッドを管理するための次のメカニズムを備えています。 - ネットワークI/Oのチューニング
クライアントとサーバーの間のネットワーク通信(T3やIIOPプロトコル、およびそれらのセキュア・バージョン)について学習します。 - ワーク・マネージャのキュー・サイズのチューニング
デフォルトでは、ワーク・マネージャの最大スレッド制約のキュー・サイズは、8,192 (8K)です。高負荷時(マシンのCPUが100%の使用率で実行されているとき)は、ワーク・マネージャ・インスタンスでこのデフォルト設定を使用してキュー内のメッセージを処理すると時間がかかる可能性があります。 - Java式の最適化
optimize-java-expression
要素を設定すると、Java式を最適化して実行時パフォーマンスを向上させることができます。 - WebLogic Serverクラスタを使用したパフォーマンスの向上
WebLogic ServerクラスタはWebLogic Serverインスタンスのグループで、互いに連携してフェイルオーバーおよびレプリケーション・サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバーに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバー群です。 - WebLogic Serverドメインのモニター
WebLogic Serverドメインを監視するための様々な方法を学習します。 - クラスおよびリソースのロードのチューニング
WebLogic Serverにおけるデフォルトのクラスおよびリソースのロードでは、デフォルトでクラスローダーの階層がルートから検索されます。その結果、クラスまたはリソースがアプリケーションに属している場合でも、クラスまたはリソースのロードが要求されるたびにシステム・クラスパス
全体が検索されます。 - SSLの考慮事項
WebLogic ServerがJDK 7で構成される場合、即時利用可能なSSLのパフォーマンス速度が以前のWebLogic Serverリリースよりも低下する場合があります。このパフォーマンスの変化は、JDK 7がWebLogic ServerでJSSEベースのSSLプロバイダとともに使用される場合にデフォルトで使用される、より強力な暗号とMACアルゴリズムが原因で起こります。
WebLogic Serverを起動するためのJavaパラメータの設定
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のチューニング
開発モードと本番モードのデフォルトのチューニング値
ドメインを使用する環境として、開発環境または本番環境のどちらかを指定できます。WebLogic Serverでは、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。
次の表の説明に従って、ドメインの起動モードを指定します。
表5-1起動モード
選択するモード | 条件 |
---|---|
開発 |
アプリケーションを作成する場合。このモードではセキュリティの構成がかなり緩和されるので、アプリケーションを自動デプロイできます。 |
本番 |
アプリケーションを最終的な形で実行する場合。このモードでは、セキュリティは完全に構成されます。 |
保護された本番 |
アプリケーションが最終的な形で実行し、頑強なポリシーおよび構成によって本番ドメインに対して高度にセキュアな環境が保証されるようにしたい場合。 |
あるドメイン・モードから別のものに切り替えることによってセキュリティおよびパフォーマンス関連の構成パラメータがどのように異なるかについては、『Oracle WebLogic Server本番環境の保護』のデフォルトのセキュリティ構成に対するドメイン・モードの影響に関する項を参照してください。
親トピック: WebLogic Serverのチューニング
デプロイメント
デプロイメント・パフォーマンスを向上させるための手法を学習します。
内部アプリケーションのオンデマンド・デプロイメント
WebLogic Serverでは、起動時に、多くの内部アプリケーションがデプロイされます。この内部アプリケーションの多くは、すべてのユーザーに必要なわけではありません。これらのアプリケーションをサーバーの起動時に常にデプロイするのではなく、最初のアクセス時に(必要に応じて)待機およびデプロイするようにWebLogic Serverを構成できます。これにより、デプロイメント時のメモリーとCPU時間が節約されるとともに、サーバーの起動時間が向上しメモリー占有量が少なくなります。開発ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってオンデマンドでデプロイされます。本番モード・ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってサーバー起動時にデプロイされます。この機能を使用および構成する方法については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の内部アプリケーションのオンデマンド・デプロイメントに関する項を参照してください。
親トピック: デプロイメント
FastSwapデプロイメントによる再デプロイメント時間の短縮
デプロイメント・モードでは、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するようWebLogic Serverを設定できます。つまり、アプリケーションが再デプロイするまで待機した後に作業していたWebページ・フローに戻るということをしないで済みます。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。
親トピック: デプロイメント
汎用オーバーライド
汎用オーバーライドでは、アプリケーション固有のファイルをオプションのAppFileOverrides
サブディレクトリにオーバーライドすることで、jarファイルを展開せずにアプリケーション固有のプロパティ・ファイルをオーバーライドできます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』の汎用ファイル・ロード・オーバーライドに関する項を参照してください。
親トピック: デプロイメント
スレッド管理
WebLogic Serverは、作業を実行するスレッドを管理するための次のメカニズムを備えています。
- ワーク・マネージャのチューニング
- 自己チューニング・スレッド・プール・サイズ
- 必要なワーク・マネージャの数
- 各ワーク・マネージャのSLA要件
- ワーク・マネージャと実行キューの相違の理解
- 以前のリリースからの移行
- スタック・スレッドの検出動作のチューニング
親トピック: WebLogic Serverのチューニング
ワーク・マネージャのチューニング
このリリースのWebLogic Serverでは、アプリケーションがどのような優先度で作業を実行するかを構成できます。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメント(SLA)が維持されます。
サーバー・インスタンスによるスレッドの利用方法をチューニングするには、ワーク・マネージャを定義して、WebLogic Serverドメインにグローバルに適用するか、特定のアプリケーション・コンポーネントに適用することにより、アプリケーションに対してルールや制約を定義します。主なチューニングの考慮事項は以下のとおりです。
『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。
親トピック: スレッド管理
自己チューニング・スレッド・プール・サイズ
スレッド・プールは、スレッドを割り当てて、サービス・サーバーおよびクライアント・サーバーのリクエストを処理します。selfTuningThreadPoolSizeMax
MBean属性のデフォルト値は400です。プロバイダとコンシューマのリクエストに応じて、プール・サイズは最大値の65534まで増やすことができます。
次の場合には、プール・サイズを増やすことをお薦めします。
-
サービス・プロバイダとサービス・コンシューマが、同じWebLogicサーバーを共有している。
-
サービス・コンシューマからの同時リクエストの数が、ワーク・マネージャの最大スレッド・プール・サイズより大きい。
-
サービス・コンシューマ・リクエストが、スレッド・プールのスレッドをすべて占有しており、リクエストにサービス・プロバイダが応答するときに使用できるスレッドがない。
『Oracle WebLogic Serverサーバー環境の管理』の自己チューニング・スレッド・プールに関する項を参照してください。
親トピック: スレッド管理
各ワーク・マネージャのSLA要件
サービス・レベル合意の(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管理コンソール・オンライン・ヘルプの実行スレッド検出動作のチューニングに関する項を参照してください。
親トピック: スレッド管理
ネットワークI/Oのチューニング
クライアントとサーバーの間のネットワーク通信(T3やIIOPプロトコル、およびそれらのセキュア・バージョン)について学習します。
親トピック: WebLogic Serverのチューニング
マキサーのチューニング
WebLogic Serverは、マキサーと呼ばれるソフトウェア・モジュールを使用して、サーバーでの受信リクエストとクライアントでの受信レスポンスを読み込みます。WebLogic Serverは、次のマキサー・タイプをサポートします。
Javaの非ブロッキングIO (NIO)マキサー
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で、遅延なしに相当します。
親トピック: マキサーのチューニング
サーバーの場所およびサポート対象プラットフォーム
WebLogic Serverのインストールおよびサポート対象プラットフォームについては、次の例を参照してください。
インストールの場所
[/home/gmcdermo/Oracle/src1221_GA] find wlserver/server/native/ -type f
wlserver/server/native/linux/x86_64/libjmsc.so
wlserver/server/native/linux/x86_64/libcloudstore1.so
wlserver/server/native/linux/x86_64/libwlenv.so
wlserver/server/native/linux/x86_64/libwlfileio3.so
wlserver/server/native/linux/x86_64/libnodemanager.so
wlserver/server/native/linux/x86_64/libweblogicunix1.so
wlserver/server/native/linux/x86_64/libipc1.so
wlserver/server/native/linux/x86_64/libwlrepstore1.so
wlserver/server/native/linux/x86_64/libmuxer.so
wlserver/server/native/linux/x86_64/wlkeytool
wlserver/server/native/linux/x86_64/rs_daemon
wlserver/server/native/linux/x86_64/rs_admin
wlserver/server/native/linux/x86_64/libstackdump.so
wlserver/server/native/linux/x86_64/libmql1.so
サポートされるプラットフォーム
ネイティブ・ライブラリでは、次のプラットフォームがサポートされています。
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/solaris/sparc64/libmuxer.so" source="wlserver/server/native/solaris/sparc64/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/solaris/sparc/libmuxer.so" source="wlserver/server/native/solaris/sparc/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/solaris/x64/libmuxer.so" source="wlserver/server/native/solaris/x64/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/solaris/x86/libmuxer.so" source="wlserver/server/native/solaris/x86/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/linux/s390x/libmuxer.so" source="wlserver/server/native/linux/s390x/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/linux/ia64/libmuxer.so" source="wlserver/server/native/linux/ia64/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/aix/ppc64/libmuxer.so" source="wlserver/server/native/aix/ppc64/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/aix/ppc/libmuxer.so" source="wlserver/server/native/aix/ppc/libmuxer.so"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/macosx/libmuxer.jnilib" source="wlserver/server/native/macosx/libmuxer.jnilib"
oracle.wls.core.app.server.nativelib/template.xml:
dest="server/native/hpux11/IPF64/libmuxer.so" source="wlserver/server/native/hpux11/IPF64/libmuxer.so"
oracle.wls.core.app.server.tier1nativelib/template.xml:
dest="server/native/linux/i686/libmuxer.so" source="wlserver/server/native/linux/i686/libmuxer.so"
oracle.wls.core.app.server.tier1nativelib/template.xml:
dest="server/native/linux/x86_64/libmuxer.so" source="wlserver/server/native/linux/x86_64/libmuxer.so"
親トピック: マキサーのチューニング
ネットワーク・チャネル
ネットワーク・チャネル(ネットワーク・アクセス・ポイントとも呼ばれる)では、ネットワーク通信の様々なサービス品質(QOS)パラメータを指定できます。各ネットワーク・チャネルは、固有IPアドレスおよびポートを使用して、排他的な独自のソケットに関連付けられます。デフォルトでは、マルチスレッド・クライアントからのT3リクエストが同じリモート接続に対して多重化され、サーバー・インスタンスがソケットからのリクエストを1つずつ読み込みます。リクエストのサイズが大きい場合、これがボトルネックになります。
ネットワーク・チャネルの主な役割はサーバー・インスタンスのネットワーク・トラフィックを制御することですが、複数のカスタム・チャネルを作成できる機能を利用すると、マルチスレッド・クライアントが、複数の接続に対してサーバー・インスタンスと通信でき、ボトルネックの危険性が軽減されます。カスタム・マルチチャネル通信を構成するには、次のステップに従います。
『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。
親トピック: ネットワークI/Oのチューニング
サービス妨害攻撃の可能性の低減
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管理コンソール・オンライン・ヘルプの接続バックログ・バッファのチューニングに関する項を参照してください。
親トピック: ネットワークI/Oのチューニング
キャッシュされた接続のチューニング
HTTP 1.1プロトコルでキープ・アライブが有効な場合に、キャッシュからソケット接続を返す動作のチューニング用のhttp.keepAliveCache.socketHealthCheckTimeout
システム・プロパティを使用します。デフォルトでは、キャッシュされた接続がクライアントに返され使用できるようになるまで、キャッシュはヘルス状態をチェックしません。ネットワーク接続が不安定な場合などの一定の条件では、クライアントに返す前にシステムが接続ヘルス状態をチェックする必要があります。この動作(ヘルス状態のチェック)を有効にするには、http.keepAliveCache.socketHealthCheckTimeout
を0より大きい値に設定します。
親トピック: ネットワークI/Oのチューニング
ワーク・マネージャのキュー・サイズのチューニング
デフォルトでは、ワーク・マネージャの最大スレッド制約のキュー・サイズは、8,192 (8K)です。高負荷時(マシンのCPUが100%の使用率で実行されているとき)は、ワーク・マネージャ・インスタンスでこのデフォルト設定を使用してキュー内のメッセージを処理すると時間がかかる可能性があります。
次の実行時例外に対応してキュー・サイズを拡大する必要がある場合があります。
java.lang.RuntimeException: [WorkManager:002943]ワーク・マネージャ"ClusterMessaging"の最大スレッド数制約"ClusterMessaging"キューが、最大容量の8,192要素に達しました。最大スレッド数制約のキュー・サイズの設定を大きくすることを検討してください。
次の例では、ターゲットはサーバー名(Server-0)によって指定され、キュー・サイズは65,536 (64K)に拡大されます。
<max-threads-constraint> <name>ClusterMessaging-max</name> <target>Server-0</target> <count>1</count> <queue-size>65536</queue-size> </max-threads-constraint> <work-manager> <name>ClusterMessaging</name> <target>Server-0</target> <max-threads-constraint>ClusterMessaging-max</max-threads-constraint> </work-manager>
サーバー名またはクラスタ名のどちらかを使用してターゲットを指定できます。サーバーまたはクラスタのどちらかをターゲット名として使用できます。
親トピック: WebLogic Serverのチューニング
Java式の最適化
optimize-java-expression
要素を設定すると、Java式を最適化して実行時パフォーマンスを向上させることができます。
『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の
jsp-descriptorに関する項を参照してください。
親トピック: WebLogic Serverのチューニング
WebLogic Serverクラスタを使用したパフォーマンスの向上
WebLogic ServerクラスタはWebLogic Serverインスタンスのグループで、互いに連携してフェイルオーバーおよびレプリケーション・サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバーに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバー群です。
ドメインには複数のWebLogic Serverクラスタと、クラスタリングされないWebLogic Serverインスタンスが存在できます。ドメイン内でクラスタリングされるWebLogic Serverインスタンスの動作は、フェイルオーバーとロード・バランシングの機能を備えること以外は、クラスタリングされないインスタンスと同様です。インスタンスのすべての構成パラメータは、そのインスタンスがクラスタリングされるかどうかにかかわらず、そのドメインの管理サーバーによって管理されます。
クラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverクラスタの理解に関する項を参照してください。
グローバル・トランザクションのクラスタ・スループットの向上の詳細は、「XAトランザクション・クラスタ・アフィニティを使用したスループットの向上」を参照してください。
親トピック: 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サーバーを直線的にスケーリングする際に影響のある問題について説明します。
データベースのボトルネック
WebLogicサーバーのクラスタがスケーリングに失敗する多くの状況では、データベースがボトルネックとなっています。こうした状況における唯一のソリューションとして、データベースをチューニングするか、他のオプションを調査してデータベース上の負荷を軽減します。「データベースのチューニング」および「データ・ソースのチューニング」を参照してください。
親トピック: WebLogicクラスタのスケーラビリティを確保する方法
セッション・レプリケーション
ユーザー・セッション・データは、2つの標準的な方法(ステートフル・セッションEJBまたはHTTPセッション)で、Java EEアプリケーションに格納できます。これらだけで、クラスタのスケーラビリティが影響されることはほとんどありません。ただし、高可用性を提供するために必要なセッション・レプリケーション・メカニズムと組み合わされると、ボトルネックが発生します。Java EEアプリケーションにWebおよびEJBコンポーネントがある場合、次の理由から、ユーザー・セッション・データはHTTPセッションに格納する必要があります。
-
HTTPセッション管理では、レプリケーション、共有DBまたは共有ファイルなど、フェイルオーバーを処理するためのオプションが多数提供されます。
-
スケーラビリティが優れています。
-
HTTPセッションの状態のレプリケーションは、すべてのトランザクションの外部で発生します。一方、ステートフル・セッションBeanのレプリケーションは、よりリソースが消費されるトランザクション内部で発生します。
-
HTTPセッションのレプリケーション・メカニズムは高度に洗練され、ステートフル・セッションBeanのレプリケーションよりも広範な状況で最適化を実現します。
「セッション管理」を参照してください。
親トピック: WebLogicクラスタのスケーラビリティを確保する方法
非同期HTTPセッション・レプリケーション
HTTPセッションの非同期レプリケーションでは、以下を使用する非同期セッション・レプリケーションを選択できます。
親トピック: WebLogicクラスタのスケーラビリティを確保する方法
セカンダリ・サーバーを使用する非同期HTTPセッション・レプリケーション
PersistentStoreTypeをasync-replicatedまたはasync-replicated-if-clusteredに設定して、プライマリ・サーバーとセカンダリ・サーバー間でのデータの非同期レプリケーションを指定します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThresholdパラメータを調整します。
レプリケーションの動作は、クラスタのタイプによって異なります。次の表では、特定のクラスタ・トポロジでの非同期レプリケーションの動作について説明します。
表5-2 クラスタ・トポロジでの非同期レプリケーションの動作
トポロジ | 動作 |
---|---|
LAN |
同一クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。 |
MAN |
リモートのクラスタのセカンダリ・サーバーにレプリケートされます。これは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。 |
WAN |
クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。リモートのクラスタを介するデータベースの永続性は、「async-replication」と「replication」のどちらが選択されていても非同期的に発生します。 |
次に、非同期レプリケーション・セッションの動作の概要を示します。
-
アンデプロイメント時または再デプロイメント時は、次のように動作します。
-
セッションが登録解除され、更新キューから削除されます。
-
セカンダリ・サーバー上のセッションが登録解除されます。
-
-
アプリケーションが管理モードに移行している場合、セッションはフラッシュされてセカンダリ・サーバーへレプリケートされます。セカンダリ・サーバーが停止している場合は、システムは別のサーバーへのフェイルオーバーを試みます。
-
セッション情報の消失の可能性を最小限に抑えるため、サーバーが停止したり障害が発生したりするとバッチ処理されたセッションのレプリケーションが発生します。
親トピック: 非同期HTTPセッション・レプリケーション
データベースを使用する非同期HTTPセッション・レプリケーション
PersistentStoreTypeをasync-jdbcに設定して、データのデータベースへの非同期レプリケーションを指定します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThresholdパラメータおよびSessionFlushIntervalパラメータを調整します。
次に、非同期レプリケーション・セッションの動作の概要を示します。
-
アンデプロイメント時または再デプロイメント時は、次のように動作します。
-
セッションが登録解除され、更新キューから削除されます。
-
セッションがデータベースから削除されます。
-
-
アプリケーションが管理モードに移行している場合、セッションはフラッシュされてデータベースへレプリケートされます。
親トピック: 非同期HTTPセッション・レプリケーション
エンティティEJBの無効化
これは、読み書きパターン付きReadOnly
またはOptimistic
の並行性戦略を使用するエンティティEJBに適用されます。
Optimistic
- Optimistic
並行性が更新されると、EJBコンテナはマルチキャスト・メッセージを他のクラスタ・メンバーに送信し、それらのBeanのローカル・コピーを無効化します。これは、オプティミスティックな並行性の例外が他のサーバーによってスローされるのを防ぐ(それによってトランザクションを再試行する必要性を回避する)ために行われます。EJBに対する更新が頻繁に行われる場合、お互いのローカル・キャッシュを無効化するためにサーバーによって行われる処理が、重大なボトルネックになります。こうした無効化をオフにするには、cluster-invalidation-disabled
と呼ばれるフラグ(デフォルトはfalse)を使用します。これは、rdbms
記述子ファイルで設定します。
読み書きパターン付きReadOnly
- このパターンでは、さもなければ単一EJBによって表される永続データが、実際には次の2つのEJBによって表されます。読込み専用EJBと更新可能EJBです。更新可能Beanの状態が変更されると、コンテナは対応する読取り専用EJBインスタンスを自動的に無効化します。EJBに対する更新が頻繁に行われる場合、読取り専用EJBを無効化するためにサーバーによって行われる処理が、重大なボトル・ネックになります。
親トピック: WebLogicクラスタのスケーラビリティを確保する方法
HTTPセッションの無効化
「エンティティEJBの無効化」と同様、HTTPセッションも無効化できます。これについては、無効化する必要があるのはセカンダリ・サーバーに格納されているセッション・データのみなので、エンティティEJBの無効化ほどコストがかかりません。HTTPセッションがもう使用されていない場合、無効化する必要があります。
親トピック: WebLogicクラスタのスケーラビリティを確保する方法
JNDIのバインド、アンバインド、およびリバインド
一般的に、JNDIのバインド、アンバインド、およびリバインドは高価な処理です。ただし、これらの処理は、クラスタ環境ではJNDIツリーの変更をクラスタのすべてのメンバーに伝播する必要があるため、大きなボトルネックになります。こうした処理が頻繁に実行される場合、クラスタのスケーラビリティが大幅に縮小する場合があります。
親トピック: WebLogicクラスタのスケーラビリティを確保する方法
マルチ・コア・マシン上でのマルチ・サーバー・インスタンスの実行
マルチ・コア・マシンについては、クラスタリングされたWebLogic Serverインスタンスと使用可能なコア数の比率を考慮する必要があります。WebLogic Serverには、クラスタ内のサーバー・インスタンス数の制限が組み込まれていないため、大規模なマルチ・コア・サーバーでは、非常に大規模なクラスタまたは多くのクラスタをホストする可能性があります。
WebLogic Serverインスタンスに対するコアの最適な比率を決定するときに次の事項を考慮してください。
-
アプリケーションのメモリー要件。個別インスタンスのヒープ・サイズとインスタンスの総合数を選択して、アプリケーションに十分なメモリーが提供されていて、よいガベージ・コレクション(GC)パフォーマンスが達成できることを確認します。いくつかのアプリケーションでは、単一のインスタンスに非常に大きなヒープ・サイズを割り当てると、ガベージ・コレクション(GC)の休止時間が長くなる場合があります。この場合は、インスタンス数を増加し、各インスタンスに小さいヒープを割り当てると、パフォーマンスが向上する場合があります。
-
CPUの最大使用。WebLogic Serverでは、インスタンスごとに複数のコアを使用できるので、いくつかのアプリケーションにおいて指定したマシン上のインスタンス数を増加(インスタンスごとにコア数の減少)すると、CPUの使用とパフォーマンスを向上できます。
WebLogic Serverドメインのモニター
WebLogic Serverドメインを監視するための様々な方法を学習します。
- 管理コンソールでのWebLogic Serverのモニター
- WebLogic診断フレームワークの使用
- JMXでのWebLogic Serverのモニター
- WLSTでのWebLogic Serverのモニター
- WebLogic Serverをモニターするためのリソース
親トピック: WebLogic Serverのチューニング
管理コンソールでのWebLogic Serverのモニター
管理コンソールは、WebLogic Serverドメインのヘルス状態とパフォーマンスをモニターするツールです。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの監視に関する項を参照してください。
親トピック: WebLogic Serverドメインのモニター
WebLogic診断フレームワークの使用
WebLogic診断フレームワーク(WLDF)は、監視および診断フレームワークであり、WebLogic Serverのプロセス内で実行する一連のサービスの定義および実装を行い、標準サーバー・ライフ・サイクルに参加します。『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDFアーキテクチャの概要に関する項を参照してください。
親トピック: WebLogic Serverドメインのモニター
JMXでのWebLogic Serverのモニター
WebLogic Serverでは、独自の一連のMBeansが提供されています。これらを使用して、WebLogic Serverリソースを構成、モニターおよび管理することができます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。
親トピック: WebLogic Serverドメインのモニター
WLSTでのWebLogic Serverのモニター
WebLogic Scripting Tool (WLST)はコマンドライン・スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。
親トピック: WebLogic Serverドメインのモニター
WebLogic Serverをモニターするためのリソース
Oracle Technology Network (http://www.oracle.com/technetwork/index.html
)では、製品のダウンロード、記事、サンプル・コード、製品ドキュメント、チュートリアル、ホワイト・ペーパー、ニュース・グループ、およびWebLogic Serverのその他の主要なコンテンツを提供しています。
親トピック: WebLogic Serverドメインのモニター
クラスおよびリソースのロードのチューニング
WebLogic Serverにおけるデフォルトのクラスおよびリソースのロードでは、デフォルトでクラスローダーの階層がルートから検索されます。その結果、クラスまたはリソースがアプリケーションに属している場合でも、クラスまたはリソースのロードが要求されるたびにシステム・クラスパス
全体が検索されます。
一度だけルックアップされるクラスやリソース(デプロイメント時のクラス・ロードなど)の場合は、classpath
全体の検索にかかる負荷が重大な問題となることは通常はありません。実行時にアプリケーションによって繰返し要求されるクラスやリソース(loadClass
またはgetResource
の明示的な呼出し)の場合は、システムやアプリケーションの長いclasspath
が繰り返し検索されることでCPUやメモリーのオーバーヘッドが増大する可能性があります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。クラスまたはリソースが見つからない場合はclasspath
の全体スキャンの負荷が発生し、アプリケーションがクラス/リソースの検索に失敗するとリクエストが繰り返される可能性があるため、さらに負荷が高まります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。
見つからないクラスまたはリソースのリクエストおよび同じクラス/リソースをロードするために頻繁に繰り返される呼出しは回避されるよう、アプリケーション・コードが最適化されているのが理想です。サード・パーティのライブラリなど、アプリケーション・コードの修正が可能でない場合は、WebLogic Serverの「フィルタリング・ローダー・メカニズム」を使用します。
フィルタリング・ローダー・メカニズム
WebLogic Serverでは、ローダーをフィルタするメカニズムが用意されています。このメカニズムを使用すると、アプリケーションのclasspath
にある特定のアプリケーション・クラスとリソースを検索するときにシステムclasspath
の検索を省略できます。このメカニズムでは、ユーザーはシステム・クラスパス
の検索を省略する特定のクラスとリソースを指定する必要があります。『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ベンダーによって異なります。
親トピック: クラスおよびリソースのロードのチューニング
SSLの考慮事項
WebLogic ServerがJDK 7で構成される場合、即時利用可能なSSLのパフォーマンス速度が以前のWebLogic Serverリリースよりも低下する場合があります。このパフォーマンスの変化は、JDK 7がWebLogic ServerでJSSEベースのSSLプロバイダとともに使用される場合にデフォルトで使用される、より強力な暗号とMACアルゴリズムが原因で起こります。
『Oracle WebLogic Serverセキュリティの管理』のSSLパフォーマンスの考慮事項に関する項を参照してください。
親トピック: WebLogic Serverのチューニング