WebLogic Server 環境のコンフィグレーション
|
 |
 |
|
WebLogic Server には、過負荷状態を検知して回避したり、過負荷状態から回復したりするための機能が備わっています。WebLogic Server の過負荷保護機能を使用すると、システムの容量が一杯になった後も要求の受け付けを継続することで生じる悪影響 (アプリケーションのパフォーマンスと安定性の低下) を回避できます。
システムの容量が一杯になった後もアプリケーション サーバが要求の受け付けを継続すると、アプリケーションのパフォーマンスと安定性が低下します。以下の節では、WebLogic Server をコンフィグレーションして、システムへの過負荷の悪影響を最小限に抑える方法について説明します。
WebLogic Server では、システム管理に関わる要求も、アプリケーション アクティビティに関わる要求も、すべて 1 つのスレッド プールで処理されます。管理者は、キューの最大長を定義することで、スレッド プールを抑制できます。コンフィグレーションした値を超えると、WebLogic Server によって要求が拒否されます。ただし、管理チャネルからの要求は拒否されません。
注意 : 管理チャネルにアクセスできるのは管理者のみです。スレッド プールの最大長に達した後も管理者がシステムにアクセスできるようにするため、実行キューの長さを制限しても、管理チャネルからの要求には影響しないようになっています。スレッド プール内の管理要求の数を制限するには、管理チャネルの最大オープン ソケット数を設定します。
キューに入っている要求の数が最大数に達すると、以下の要求が即座に拒否され始めます。
スレッド プールを抑制するには、Administration Console の [Max execute queue Length] フィールド ([環境｜サーバ｜スレッド] で実行キューを選択) を設定します。このフィールドのデフォルト値は 65536 です。
ワーク マネージャをコンフィグレーションすることで、スレッド プールをより細かいレベル (パフォーマンス、可用性、信頼性の要件が似ている要求のセット) で管理できます。ワーク マネージャでは、特定の要求クラスの要求を、いくつまでキューに入れることができるかを指定できます。ワーク マネージャで定義した最大要求数は、グローバル スレッド プールの値と併用されます。先に制限値に達したほうが優先されます。
「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
管理者は、低メモリ状態の検知に基づいて、アクティブな HTTP セッションの数を制限できます。これは、メモリ不足状態を回避する上で便利な機能です。
コンフィグレーションしたしきい値に達すると、新しい HTTP セッションを作成する要求が拒否されます。WebLogic Server クラスタでは、拒否された要求がプロキシ プラグインによってクラスタ内の別の管理対象サーバにリダイレクトされます。クラスタ化されていないサーバ インスタンスの場合は、要求を代替サーバ インスタンスにリダイレクトできます。
サーブレット コンテナは、セッション数が最大数に達すると以下のいずれかのアクションを実行します。
同時 HTTP セッション数の制限は、Web アプリケーションのデプロイメント記述子で設定します。たとえば、次の要素ではセッション数の制限が 12 に設定されています。
<session-descriptor>
<max-in-memory-sessions>12</max-in-memory-sessions>
</session-descriptor>
管理者は、メモリ不足例外が発生したら WebLogic Server が終了するようにコンフィグレーションできます。この機能を使用すると、自動停止によってアプリケーションが不安定になるのを回避でき、メモリ不足状態の影響を最小限に抑えることができます。ダウン タイムを最短にするには、ノード マネージャなどの HA ツールを使用して WebLogic Server が自動的に再起動するようにコンフィグレーションします。
この自動停止をコンフィグレーションするには、Administration Console を使用するか、config.xml で次のように要素を編集します。
<overload-protection>
<panic-action>system-exit</panic-action>
</overload-protection>
詳細については、OverloadProtectionMBean の属性を参照してください。
WebLogic Server では、スタック スレッドが定期的にチェックされます。すべてのアプリケーション スレッドがスタックすると、サーバ インスタンスが障害が発生したものとしてマークされ、終了するようにコンフィグレーションされていれば終了します。障害から自動的に回復するようにするには、ノード マネージャやサード パーティの高可用性ソリューションでサーバが再起動するようにコンフィグレーションします。
すべてのアプリケーション スレッドがスタックしたときにサーバ インスタンスが終了するようにコンフィグレーションするには、Administration Console の [サーバ｜Overload Protection] ページで [Exit server process on detecting deadlock] オプションをチェックします。
すべてのスレッドがスタックしていなくても、スタック スレッドの数がコンフィグレーションしたしきい値を超えたら、これらのアクションが発生するようにコンフィグレーションできます。
詳細については、OverloadProtectionMBean の属性を参照してください。
以下の節では、過負荷状態を検知して報告するための WebLogic Server 機能について説明します。
WebLogic Server では、新しいヘルス状態としてオーバーロードが追加されました。このヘルス状態は、ライフ サイクルの状態が実行中になっているサーバ インスタンスが過負荷状態になると、ServerRuntimeMBean.getHealthState() によって返されます。この状態が発生するのは、ワーク マネージャの容量を超過したときや、低メモリ状態になったときです。
過負荷状態が解消すると、サーバ インスタンスのヘルス状態は OK に戻ります。オーバーロードになったサーバ インスタンスは、管理者が中断または停止できます。
WebLogic Server が終了すると、終了コードが返されます。終了コードは、シェル スクリプトや HA エージェントがサーバの再起動が必要かどうかを決定するために使用できます。『サーバの起動と停止の管理』の「WebLogic Server の終了コードと障害後の再起動」を参照してください。
|
|
|