| Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の構成 11g リリース1 (10.3.6) B60987-04 |
|
 前 |
 次 |
この章では、WebLogic Serverによる過負荷状態の検出、回避、およびそこからの復旧に関する仕組みについて説明します。WebLogic Serverの過負荷保護機能を使用すると、システムの容量が一杯になった後もリクエストの受け付けを継続することで生じる悪影響(アプリケーションのパフォーマンスと安定性の低下)を回避できます。
システムの容量が一杯になった後もアプリケーション・サーバーがリクエストの受け付けを継続すると、アプリケーションのパフォーマンスと安定性が低下します。次の項では、WebLogic Serverを構成して、システムへの過負荷の悪影響を最小限に抑える方法について説明します。
WebLogic Serverでは、システム管理に関わるリクエストも、アプリケーション・アクティビティに関わるリクエストも、すべて1つのスレッド・プールで処理されます。管理者は、キューの最大長を定義することで、スレッド・プールを抑制できます。構成した値を超えると、WebLogic Serverによってリクエストが拒否されます。ただし、管理チャネルからのリクエストは拒否されません。
|
注意: 管理チャネルにアクセスできるのは管理者のみです。スレッド・プールの最大長に達した後も管理者がシステムにアクセスできるようにするため、実行キューの長さを制限しても、管理チャネルからのリクエストには影響しないようになっています。スレッド・プール内の管理リクエストの数を制限するには、管理チャネルのMaxConnectedClients属性を設定します。 |
キューに入っているリクエストの数が最大数に達すると、以下のリクエストが即座に拒否され始めます。
Webアプリケーション・リクエスト
フェア・シェアが低い(最小のフェア・シェアで始まる)トランザクション非対応のRMIリクエスト。
過負荷状態が継続する場合は、より優先順位の高いリクエストが拒否され始めます。ただし、JMSリクエストとトランザクション関連のリクエストは、JMSおよびトランザクション・マネージャによって過負荷管理されるため、ここでは対象外となります。
スレッド・プールを制限するには、管理コンソールの「ワーク・マネージャの共有容量」フィールド(「環境」>「サーバー>「server_name」>「構成」>「オーバーロード」を参照してください)を設定します。このフィールドのデフォルト値は65536です。
ワーク・マネージャを構成することで、スレッド・プールをより細かいレベル(パフォーマンス、可用性、信頼性の要件が似ているリクエストのセット)で管理できます。ワーク・マネージャでは、特定のリクエスト・クラスのリクエストを、いくつまでキューに入れることができるかを指定できます。ワーク・マネージャで定義した最大リクエスト数は、グローバル・スレッド・プールの値と併用されます。先に制限値に達したほうが優先されます。
第2章「ワーク・マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
管理者は、低メモリー状態の検知に基づいて、アクティブな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が自動的に再起動するように構成し、ダウンタイムを最短にできます。
これを構成するには、管理コンソールを使用するか、config.xmlで次のように要素を編集します。
<overload-protection> <panic-action>system-exit</panic-action> </overload-protection>
詳細は、OverloadProtectionMBeanの属性を参照してください。
WebLogic Serverでは、スタック・スレッドが定期的にチェックされます。すべてのアプリケーション・スレッドがスタックすると、サーバー・インスタンスが障害が発生したものとしてマークされ、終了するように構成されていれば終了します。障害から自動的にリカバリするようにするには、ノード・マネージャやサード・パーティの高可用性ソリューションでサーバーが再起動するように構成します。
すべてのスレッドがスタックしていなくても、スタック・スレッドの数が構成したしきい値を超えたら、これらのアクションが発生するように構成できます。
スタック・スレッドのあるワーク・マネージャを停止します。停止したワーク・マネージャは、新しい作業を拒否するとともに、拒否メッセージを送信してキュー内の既存の作業を拒否します。クラスタでは、クラスタリングされたクライアントが別のクラスタ・メンバーにフェイルオーバーします。
アプリケーション内にスタック・スレッドがある場合は、そのアプリケーションが停止します。アプリケーションは、管理モードに移行することで停止します。アプリケーションに属するすべてのワーク・マネージャが停止し、前項で説明した動作が行われます。
サーバー内にスタック・スレッドがある場合は、サーバー・インスタンスが障害が発生したものとしてマークし、停止します。クラスタでは、クラスタリングされたクライアントのうち、接続されているか接続を試行しているクライアントが別のクラスタ・メンバーにフェイルオーバーします。
詳細は、OverloadProtectionMBeanの属性を参照してください。
次の項では、過負荷状態を検知して報告するためのWebLogic Server機能について説明します。
WebLogic Serverでは、ヘルス状態としてOVERLOADEDがあり、このヘルス状態は、ライフ・サイクルの状態がRUNNINGになっているサーバー・インスタンスが過負荷状態になると、ServerRuntimeMBean.getHealthState()によって返されます。この状態が発生するのは、低メモリー状態になったときです。
OVERLOADED状態になると、サーバー・インスタンスがワーク・マネージャのキューからのリクエストの拒否を開始し(ワーク・マネージャが構成されている場合)、HTTPリクエストが503エラー(サービス利用不可)を返します。また、クラスタリングされている場合はRMIリクエストが別のサーバーにフェイルオーバーされ、クラスタリングされていない場合はクライアントにリモート例外が返されます。
過負荷状態が解消すると、サーバー・インスタンスのヘルス状態はOKに戻ります。オーバーロードになったサーバー・インスタンスは、管理者が一時停止または停止できます。
WebLogic Serverが終了すると、終了コードが返されます。シェル・スクリプトまたはHAエージェントは、終了コードを使用して、サーバーを再起動するかどうかを判断します。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic Serverの終了コードと障害後の再起動を参照してください。
