ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション
11g リリース 1 (10.3.1)
B55510-01
  目次
目次

戻る
戻る
 
次へ
次へ
 

3 過負荷の回避と管理

WebLogic Server には、過負荷状態を検知して回避したり、過負荷状態から回復したりするための機能が備わっています。WebLogic Server の過負荷保護機能を使用すると、システムの容量が一杯になった後も要求の受け付けを継続することで生じる悪影響 (アプリケーションのパフォーマンスと安定性の低下) を回避できます。

過負荷状態を回避するための WebLogic Server のコンフィグレーション

システムの容量が一杯になった後もアプリケーション サーバが要求の受け付けを継続すると、アプリケーションのパフォーマンスと安定性が低下します。以下の節では、WebLogic Server をコンフィグレーションして、システムへの過負荷の悪影響を最小限に抑える方法について説明します。

スレッド プール内の要求数の制限

WebLogic Server では、システム管理に関わる要求も、アプリケーション アクティビティに関わる要求も、すべて 1 つのスレッド プールで処理されます。管理者は、キューの最大長を定義することで、スレッド プールを抑制できます。コンフィグレーションした値を超えると、WebLogic Server によって要求が拒否されます。ただし、管理チャネルからの要求は拒否されません。


注意 :

管理チャネルにアクセスできるのは管理者のみです。スレッド プールの最大長に達した後も管理者がシステムにアクセスできるようにするため、実行キューの長さを制限しても、管理チャネルからの要求には影響しないようになっています。スレッド プール内の管理要求の数を制限するには、管理チャネルの MaxConnectedClients 属性を設定します。

キューに入っている要求の数が最大数に達すると、以下の要求が即座に拒否され始めます。

  • Web アプリケーション要求

  • フェア シェアが低い (最小のフェア シェアで始まる) トランザクション非対応の RMI 要求

    過負荷状態が継続する場合は、より優先順位の高い要求が拒否され始めます。ただし、JMS 要求とトランザクション関連の要求は、JMS およびトランザクション マネージャによって過負荷管理されるため、ここでは対象外となります。

スレッド プールを抑制するには、Administration Console の [ワーク マネージャの共有容量] フィールド ([環境サーバスレッド] で実行キューを選択) を設定します。このフィールドのデフォルト値は 65536 です。

ワーク マネージャとスレッド プールの抑制

ワーク マネージャをコンフィグレーションすることで、スレッド プールをより細かいレベル (パフォーマンス、可用性、信頼性の要件が似ている要求のセット) で管理できます。ワーク マネージャでは、特定の要求クラスの要求を、いくつまでキューに入れることができるかを指定できます。ワーク マネージャで定義した最大要求数は、グローバル スレッド プールの値と併用されます。先に制限値に達したほうが優先されます。

ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

HTTP セッションの制限

管理者は、低メモリ状態の検知に基づいて、アクティブな HTTP セッションの数を制限できます。これは、メモリ不足状態を回避するうえで便利な機能です。

コンフィグレーションしたしきい値に達すると、新しい HTTP セッションを作成する要求が拒否されます。WebLogic Server クラスタでは、拒否された要求がプロキシ プラグインによってクラスタ内の別の管理対象サーバにリダイレクトされます。クラスタ化されていないサーバ インスタンスの場合は、要求を代替サーバ インスタンスにリダイレクトできます。

サーブレット コンテナは、セッション数が最大数に達すると以下のいずれかのアクションを実行します。

  • サーバ インスタンスがクラスタ内にある場合は SessionCreationException が送出される。作成するアプリケーション コードでは、この実行時例外を処理して適切な応答を送信する必要があります。

    過負荷保護を実装するためには、この例外を処理して 503 応答を明示的に送信する必要があります。この応答は、プロキシまたはロード バランサで処理できます。

同時 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 では、スタック スレッドが定期的にチェックされます。すべてのアプリケーション スレッドがスタックすると、サーバ インスタンスが障害が発生したものとしてマークされ、終了するようにコンフィグレーションされていれば終了します。障害から自動的に回復するようにするには、ノード マネージャやサード パーティの高可用性ソリューションでサーバが再起動するようにコンフィグレーションします。

すべてのスレッドがスタックしていなくても、スタック スレッドの数がコンフィグレーションしたしきい値を超えたら、これらのアクションが発生するようにコンフィグレーションできます。

  • スタック スレッドのあるワーク マネージャを停止する。停止したワーク マネージャは、新しい作業を拒否するとともに、拒否メッセージを送信してキュー内の既存の作業を拒否します。クラスタでは、クラスタ化されたクライアントが別のクラスタ メンバーにフェイルオーバします。

  • アプリケーション内にスタック スレッドがある場合は、そのアプリケーションが停止する。アプリケーションは、管理モードに移行することで停止します。アプリケーションに属するすべてのワーク マネージャが停止し、前項で説明した動作が行われます。

  • サーバ内にスタック スレッドがある場合は、サーバ インスタンスが障害が発生したものとしてマークされて停止する。クラスタでは、クラスタ化されたクライアントのうち、接続されているか接続を試行しているクライアントが別のクラスタ メンバーにフェイルオーバします。

詳細については、OverloadProtectionMBean の属性を参照してください。

WebLogic Server の自動モニタ

以下の節では、過負荷状態を検知して報告するための WebLogic Server 機能について説明します。

過負荷ヘルス状態

WebLogic Server では、ヘルス状態として「オーバーロード」が追加されました。このヘルス状態は、ライフ サイクルの状態が「実行中」になっているサーバ インスタンスが過負荷状態になると、ServerRuntimeMBean.getHealthState() によって返されます。この状態が発生するのは、低メモリ状態になったときです。

オーバーロード状態になると、サーバ インスタンスがワーク マネージャのキューからのリクエストの拒否を開始し (ワーク マネージャがコンフィグレーションされている場合)、HTTP リクエストが 503 エラー (サービスの使用不能) を返します。また、クラスタ化されている場合は RMI リクエストが別のサーバにフェイルオーバされ、クラスタ化されていない場合はクライアントにリモート例外が返されます。

過負荷状態が解消すると、サーバ インスタンスのヘルス状態は OK に戻ります。オーバーロードになったサーバ インスタンスは、管理者が中断または停止できます。

WebLogic Server の終了コード

WebLogic Server が終了すると、終了コードが返されます。終了コードは、シェル スクリプトや HA エージェントがサーバの再起動が必要かどうかを決定するために使用できます。『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止の管理』の「WebLogic Server の終了コードと障害後の再起動」を参照してください。