この章の内容は次のとおりです。
リソース消費管理(RCM)は、共有リソースを管理し、MT環境でドメイン・パーティションの一貫したパフォーマンスを提供するために、WebLogic Serverシステム管理者に柔軟性のある動的なメカニズムを提供します。
RCMポリシーは、リソース・マネージャとして構成されます。ドメイン・レベルのグローバル・スコープでリソース・マネージャを作成して、ドメイン内の任意のパーティションに対してRCMポリシーとして使用できます。パーティションにそのパーティションに固有のRCM特性がある場合は、パーティション・スコープのリソース・マネージャを作成することもできます。「リソース消費管理の構成: 主な手順」を参照してください
アプリケーションが複数のドメイン・パーティションにデプロイされた場合、低レベルのリソース(CPU、ヒープ、ネットワーク、ファイル・ディスクリプタなど)を共有すると、リソース割当てが不公平になる可能性があります。高トラフィック、アプリケーション設計、悪質なコードなどの様々な理由により、異常なリソース消費のリクエストが発生する可能性があります。これらのリクエスト・タイプにより、別に配置されたドメイン・パーティションがリソースにアクセスしないように、共有リソースの容量が過負荷となります。ドメイン・パーティション・レベルで適切なRCMポリシーを使用することによって、リソース消費管理は、あるパーティションのアプリケーションが他のパーティションのアプリケーションに悪影響を及ぼさないようにします。
次のJVM引数を設定して、環境内でRCMを有効化します。
-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC
このフラグは、RCMが有効化されるすべてのサーバー・インスタンス(JVM)に適用する必要があります。
代替方法は、ドメインの作成時に作成されるstartWeblogic.sh
ファイル内の次のJAVA_OPTIONS
をコメント解除することです。
#JAVA_OPTIONS="-XX:+UnlockCommercialFeatures -XX:+ResourceManagement -XX:+UseG1GC ${SAVE_JAVA_OPTIONS}
これは、各サーバー・インスタンスで行う必要があり、WebLogic Serverインスタンスの起動前に行う必要があります。
WebLogic ServerでJavaセキュリティ・マネージャが使用される場合、RCMは、weblogic.policy
で次の権限を付与する必要があります。
permission RuntimePermission("jdk.management.resource.getResourceContextFactory")
Javaセキュリティ・マネージャを使用したWeblogic Serverのリソースの保護の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaセキュリティ・マネージャを使用したWebLogicリソースの保護に関する項を参照してください。
システム管理者は、リソース・マネージャを使用して、ドメインのパーティションごとに共有リソースに対するリソース消費管理ポリシーを指定します。リソース・マネージャは、1つ以上の共有リソースに対する1つ以上のポリシーで構成されます。各ポリシーは、リソースに対する制約値と、制約値に達したときにWebLogic Serverインスタンスによって実行される指定されたアクションで構成されます。
次のRCMポリシー・タイプがサポートされています。
トリガーは、許可されるリソース使用量の静的制約値を定義します。そのリソースの使用量が制約値を超えると、指定したアクションが実行されます。このポリシー・タイプは、ドメインのパーティションによるリソース使用量が予測可能である環境に最適です。
システム管理者は、トリガー・ポリシーの作成時に、次のアクションを選択できます。
Notify
: 制約値に達したことがシステム管理者に通知されます。リソースに複数のNotify
トリガーを追加できます。たとえば、Open Files
が20を超えたときにNotify
、Open Files
が50を超えたときにNotify
などです。また、WebLogic診断フレームワーク(WLDF)を使用して、ログ・メッセージをリスニングするようにウォッチ・ルールを作成し、拡張通知を行うことができます。
Slow
: リソースの消費率を低下します。Slow
アクションがトリガーされると、パーティション・ワーク・マネージャのフェア・シェア値が減少し、パーティションで使用可能になったthread-usage time
が減少します。パーティション・ワーク・マネージャの詳細は、「パーティション・ワーク・マネージャの構成」を参照してください。
Fail
: 使用量が制約値を下回るまで、リソースのリソース消費リクエストが失敗します。
注意:
Fail
はOpen Files
に対してのみ適用可能で、その他のリソースには適用できません。
たとえば、パーティションP1の開かれたファイルの数を100ファイル未満に制限するには、P1パーティションに対してOpen Files
リソースの100個の制約値とFail
アクションを持つトリガー・ポリシーを含むリソース・マネージャを作成します。
Shutdown
: クリーンアップを許可しているときにパーティションの停止を開始します。このアクションは、パーティションが既知の制約値を超え、ドメイン内の他のパーティションによって使用される共有リソースの悪影響が予想される場合に役立ちます。パーティションは、制約値に達した管理対象サーバーでのみ停止し、クラスタ環境での継続的な可用性が実現します。Fail
トリガーとShutdown
トリガーは一緒に使用しないでください。
Restart
: パーティションのリソース消費量の割当て違反が発生しているサーバー・インスタンスでパーティションを再起動します。多くの場合、アプリケーションが一時的に誤動作しており、単に再起動することで状況が修正されます。システム管理者の介入が必要となる場合もありますが、このパーティションの自動再起動アクションを有効にするほうが理想的です。その他のRCMアクションと同様、パーティションの再起動アクションは特定の管理対象サーバーにのみスコープ指定されています。
さらに、パーティションの再起動がループすることを防ぐために、次のオプションの構成プロパティを指定できます。
max-restart-allowed
指定した期間内で許容される、RCMで始動されたパーティションの再起動の最大数。これを超えると、RCM始動のパーティションの再起動リクエストでパーティションが一時停止されます。
max-restart-allowed-interval
max-restart-allowed-interval
は、指定した数(max-restart-allowed
)のRCM始動のパーティションの再起動が許可される、固定幅のスライディング・ウィンドウ期間(秒単位)です。max-restart-allowed-interval
内にmax-restart-allowed
数を超えるパーティションの再起動リクエストがあると、パーティションは再起動されず、一時停止されます。
restart-delay
パーティションを起動する前に組み込まれる遅延(秒単位)。
RCMポリシーでのこれらのプロパティは、config.xml
ファイルの<resource-manager>
で定義できます。特定のRCMポリシー内のすべての再起動アクションが、これらの構成可能プロパティの値を共有します。管理者は、パーティションが再起動されるときの再起動の遅延も指定できます。構成された遅延はパーティションの起動前に組み込まれ、パーティションが短期間に繰り返し再起動されたり、一時的な外部エラー状態が解消されるよりも前に再起動されることを防ぎます。
次に、RCM再起動アクションのサンプル構成を示します。
<resource-manager> <name>ResourceManager-1</name> <restart-loop-protection> <!--This indicates whether restart loop protection is enabled or not. If you want to disable the restart loop protection, set this flag to false. --> <restart-loop-protection-enabled>true</restart-loop-protection-enabled> <!-- The partition can be restarted a maximum of 3 times in 60 minutes by the RCM restart action. Subsequently, the partition would be halted. --> <max-restart-allowed>3</max-restart-allowed> <!-- Within any contiguous interval of 60 minutes, a maximum number of 3 restarts are allowed, as specified by the max-restart-allowed property. --> <max-restart-allowed-interval>3600</max-restart-allowed-interval> <!-- Introduce a delay of 10 seconds before starting the partition. --> <restart-delay>10</restart-delay> </restart-loop-protection> <file-open> <name>RM1-FileOpenResource</name> <trigger> <name>RM1-Trigger-1</name> <value>20</value> <action>restart</action> </trigger> </file-open> </resource-manager>
構成された再起動アクションのトリガーを超えると、次の図に示すようにパーティションの再起動リクエストが生成されます。
注意:
ポリシー・アクションは、アクション・タイプに応じて同期的にも非同期的にも実装されます。たとえば、Fail
アクションは、開いているファイルをリクエストしたスレッドを同期的に使用します。その他のアクション(Heap Retained
リソースに構成されたSlow
アクションなど)は、非同期的に続行します。
フェア・シェア・ポリシーにより、システム管理者が、ドメイン内の各パーティションの代表的な負荷に基づき、シェア(使用可能リソースのパーセンテージ)を割り当てることができます。フェア・シェア・ポリシーが使用されるのは、リソースの使用量の正確な要件を決定できない場合、またはリソースを効率的および公平に利用できるようにリソース・マネージャを使用する際に実装することが現実的ではない場合です。特定のリソースについてドメインのパーティション間で競合がない場合、各パーティションでその即時のワークロードに必要なリソースの量を使用できます。特定のリソースについてパーティション間で競合がある場合、各パーティションは使用可能リソースのフェア・シェアのみの使用に制約されます。メモリー消費全体が使用可能な最大メモリー(メモリー不足例外となる)を超えないように、制限が設定されていることを確認します。
シェアは、リソースの指定された量を使用するための割当てです。システム管理者が、関連するリソース・マネージャのフェア・シェア・ポリシーで1から1000までの整数値を指定して、パーティションにシェアを割り当てます。ドメインの同じリソースのすべてのフェア・シェア値の合計に対する、特定のパーティションのその構成されたフェア・シェア値の比率によって、割り当てられるリソースの量が決定します。
たとえば、システム管理者がパーティションP1でリソースに対して150のフェア・シェア値を指定し、パーティションP2で同じリソースに対して100の値を指定します。ワークロードが両方のパーティションでそのリソースの競合を作成するのに十分に高い場合、パーティションP1のリソース割当ては、150/(150+100)または使用可能なリソースの60パーセントです。
リソース・マネージャは、1つ以上の共有リソースに対する1つ以上のポリシーで構成されます。各ポリシーは、リソースに対する制約値と、制約値に達したときにWebLogic Serverインスタンスによって実行される指定されたアクションで構成されます。
リソース・マネージャを構成するには、次を参照してください。
『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・マネージャの作成に関する項。
次の例は、「リソース消費管理の構成: WLSTの例」に表示されたWLSTの例に類似した、注釈が付いたRCM構成です。
<domain> ... <!--Define RCM Configuration --> <resource-management> <resource-manager> <name>Approved</name> <file-open> <trigger> <name>Approved2000</name> <value>2000</value><!-- in units--> <action>shutdown</action> </trigger> <trigger> <name>Approved1700</name> <value>1700</value> <action>slow</action> </trigger> <trigger> <name>Approved1500</name> <value>1500</value> <action>notify</action> </trigger> </file-open> <heap-retained> <trigger> <name>Approved2GB</name> <value>2097152</value> <action>shutdown</action> </trigger> <fair-share-constraint> <name>FS-ApprovedShare</name> <value>60</value> </fair-share-constraint> </heap-retained> </resource-manager> <resource-manager> <name>Trial</name> <file-open> <trigger> <name>Trial1000</name> <value>1000</value><!-- in units--> <action>shutdown</action> </trigger> <trigger> <name>Trial700</name> <value>700</value> <action>slow</action> </trigger> <trigger> <name>Trial500</name> <value>500</value> <action>notify</action> </trigger> </file-open> ... </resource-manager> <resource-manager> <name>RestartPartition</name> <file-open> <name>FileOpenQuota</name> <trigger> <name>MaxFileOpenAllowed</name> <value>20</value> <action>restart</action> </trigger> </file-open> <restart-loop-protection> <restart-loop-protection-enabled>true</restart-loop-protection-enabled> <max-restart-allowed>3</max-restart-allowed> <max-restart-allowed-interval>3600 </max-restart-allowed-interval> <restart-delay>10</restart-delay> </restart-loop-protection> </resource-manager> </resource-management> <partition> <name>Partition-0</name> <resource-group> <name>ResourceTemplate-0_group</name> <resource-group-template>ResourceTemplate-0</resource-group-template> </resource-group> ... <partition-id>1741ad19-8ca7-4339-b6d3-78e56d8a5858</partition-id> <!-- RCM Managers are targeted to partitions during partition creation or later by system administrators. --> <resource-manager-ref>Approved</resource-manager-ref> ... </partition> .. </domain>
ドメイン・パーティションから、リソース管理ポリシーを動的に適用または削除できます。リソース管理ポリシーへの変更は、そのポリシーを使用するすべてのドメイン・パーティションに適用されます。
アクティブなドメイン・パーティションのポリシー更新が、リソースの現在の使用量より低いリソースに対してトリガー値を設定した場合、そのリソースのその後の使用量には、ポリシーのリコース・アクションが適用されています。ポリシーを変更すると、現在の使用量の値に基づいてアクティブなドメイン・パーティションが即時停止される場合、その変更は、動的再構成の変更として受け入れられません。
パーティション内の共有リソースのRCMメトリックは、PartitionResourceMetricsRuntimeMBean
を介して使用可能になります。
これらのメトリックは次のために使用できます。
パーティションでの現在のリソース使用量をモニターします。
パーティションのリソース消費をプロファイルおよび分析して、有効なリソース・マネージャとWLDFウォッチおよび通知を作成するために必要な、代表的な負荷、ピーク負荷、ピーク負荷時間などのデータを生成します。
Fusion Middleware Controlでリソース・マネージャをモニターするには、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のリソース・マネージャのモニターに関する項を参照してください。
デフォルトでは、リソース・メーターの即時登録は無効です。そのため、特定のリソースについてリソース消費メトリックの問合せが初めて行われたときに作成されます。その場合、リソース・アカウンティングが遅れて開始されていて、リソース消費メトリックから返される値がパーティションで消費されたリソースの実際の値と異なることがあります。
パーティションで消費されたリソース量が正しく反映された値を得るには、メーターをパーティションの起動時に即座に登録する必要があります。リソース・メーターの即時登録を有効にするには、WebLogic Serverインスタンスの起動時に、JVM引数としてweblogic.rcm.enable-eager-resource-meter-registration
プロパティをtrue
に設定します。
次の各項では、リソース管理ポリシーを開発するシステム管理者のベスト・プラクティスと考慮事項について説明します。
リコース・アクションは、システム管理者が慎重に選択する必要があります。多くのリソース間には、複雑な相互作用があります。たとえば、CPU使用率を低下させる(その結果、ドメイン・パーティションに割り当てられるスレッドが少なくなる)と、ヒープの常駐が増加し、これによって維持されるヒープ使用量に影響を与える可能性があります。
遅れたリコース・アクションを有効にするために、アプリケーションがスレッドを作成または管理することはできません。アプリケーションで、WebLogic Serverの機能(EJBタイマー、Common Jワーク・マネージャおよびタイマー、管理対象エグゼキュータ・サービス、バッチAPIなど)のいずれかを使用して、遅れたリコース・アクションが有効になるようにタスクを管理することをお薦めします。
RCMポリシーを指定する前に、システム管理者は、平均とピークのリソースの使用率データをモニターし、十分なヘッドルームでポリシーを構成して、リソースを効率的に使用することとサービス・レベル合意(SLA)を満たすことのバランスをとることをお薦めします。「リソース消費管理の構成: リソース使用量のモニタリング」を参照してください。
対応するトリガーを実行する必要がある正確な限度を管理者が認識している場合に、トリガーを使用します。トリガーは、ファイルなどのリソースに対して構成されたしきい値を超えると実行され、ヒープやCPUなどのリソースに対して遅れる可能性があります。
フェア・シェア・ポリシーは、通常、バインド・サイズ共有のリソースが、競合するコンシューマによって効率的に(かつ十分に)共有されていることをシステム管理者が確認するために使用します。また、フェア・シェア・ポリシーは、パーティションによるリソースの正しい使用量を事前に正確に決定できないことをよく理解している場合に、システム管理者によって使用することもでき、システム管理者は、共在するパーティションへの共有リソースの公平な割当てが確実に行われるようにしながら、リソースを有効に利用します。パーティション間のリソースに補足的ワークロードがある場合に、環境内でフェア・シェア・ポリシーを使用します。「補足的ワークロードの使用」を参照してください
可能な場合は、パーティション間でピーク使用時間のバランスを調整してリソースの密度を最大化することで、ピーク使用時間が重複せず、かつ、それらの平均の合計が最大ピーク値を超えないようにします。一方、対立するワークロードがある場合、ピーク使用時間が重複し、平均の合計が最大のピーク値を超過します。
異なるリソースを実行するパーティション・ワークロードを配置することも考えてみます。たとえば、大部分がCPUバインドされたワークロードを持つパーティションと、メモリー・バインドされたワークロードを持つ別のパーティションをホストすると、密度および全体的なリソース使用状況が改善されます。
パーティションに固有のリソース要件がある場合に、パーティション・スコープの動的なRCMポリシーを使用します。これらのポリシーにより、既存のドメインに対するパーティションRCMポリシーのインポートおよびエクスポートが容易になります。
リソース管理ポリシーがパーティションで明示的に設定されていない場合、そのパーティションの使用可能な共有リソースへのアクセスには制約がありません。
CPU使用率は、配置されたドメイン・パーティションによってCPUの競合を追跡する優れたメトリックで、CPUバインドされたワークロードのフェア・シェア・ポリシーで特に役立ちます。CPU使用率を最大化するためにRCMポリシーを使用する場合は、次のことを考慮します。
ドメイン内のすべてのパーティションのワークロード(統合ワークロード)を考慮したときに、CPUのピーク使用率がCPUの平均使用率を大きく超えないようにする必要があります。CPUのピーク負荷とCPUの平均負荷の差を最小化すると、ドメインのCPU使用率を最大化できます。
CPU使用率の約75%がドメインのパーティションに格納されたアプリケーションに使用されるようにRCMのCPUポリシーを構成することをお薦めします。残りの25%の10%ほどは操作タスク(バックアップ、スケジュール済タスクおよびその他の管理)に、15%ほどはクラスタ・フェイルオーバーに割り当てる必要があります。
次のRCMの制限事項に注意してください。
ヒープ・リソース消費の追跡および管理は、G1ガベージ・コレクタで実行される場合のみサポートされます(他のJDKコレクタではRCMはサポートされません)。
JNI/ネイティブ・コードで発生するアクティビティのリソース消費メトリックの測定および計上はサポートされていません。
保持されるヒープとCPU使用率の測定は非同期的に実行されるため、現在の(ポイント・イン・タイムの)値を表しません。
静的フィールド内のオブジェクトのヒープ使用状況の区別、およびシステムからロードされたクラスおよび共有クラス・ローダーのシングルトン・オブジェクトに問題があり、最終会計値で正確に表されない可能性があります。システムからロードされたクラスおよび共有クラス・ローダーのインスタンスがパーティションによってロードされた場合、インスタンスのヒープの使用がそのパーティションに対して計上されます。
ガベージ・コレクション・アクティビティは、Oracle JDK 8u40を使用したWebLogic Server 12.2.1の特定のドメイン・パーティションに分離されません。
サーバー・インスタンスでリソース消費の追加の追跡および管理が発生するため、RCM機能を有効にする際にパフォーマンスへの悪影響があります。
WLSTを使用して、RCMポリシーを実装およびモニターできます。
次に、WLSTを使用してRCM構成を作成する例を示します。この例では、システム管理者によって次が定義されています。
ドメインのすべてのProduction層を持つドメイン・パーティションに対してシステム管理者が確立する一連のリソース消費管理ポリシーを表すProductionリソース・マネージャ。Productionリソース・マネージャには様々なリソースに対するポリシーがあります。
FileOpen
リソース・タイプには、3つのトリガーが指定されています。Production2000
トリガーにより、開いているファイル・ディスクリプタの数が2000に達したときにパーティションが停止されます。Production1700
トリガーにより、開いているファイル・ディスクリプタの数が1700を超えたときに、ドメイン・パーティションを低速化する必要があることが指定されています。Production1500
トリガーにより、通知アクションが指定されます。
HeapRetained
リソース・タイプでは、Production2GB
トリガーが作成され、パーティションの保持されるヒープ値が2GBに達したときにパーティションが停止されます。Productionリソース・マネージャに、60のフェア・シェア値が割り当てられています。
Trialリソース・マネージャは同様に定義しますが、一連のポリシーが減少します。
Partition-0
という名前のパーティション。
このスクリプトが完了すると、Partition-0
にProductionリソース・マネージャが割り当てられます。
「RCMのWLSTの例: 概要」で説明されているポリシーは、次の例に示すWLSTスクリプトを使用して作成できます。
startEdit() cd('/ResourceManagement') cd(domainName) rm=cmo.createResourceManager('Approved') fo=rm.createFileOpen('Approved-FO') fo.createTrigger('Approved2000',2000,'shutdown') fo.createTrigger('Approved1700',1700,'slow') fo.createTrigger('Approved1500',1500,'notify') hr=rm.createHeapRetained('Approved-HR') hr.createTrigger('Approved2GB',2097152,'shutdown') hr.createFairShareConstraint('FS-ApprovedShare', 60) cd('/ResourceManagement') cd(domainName) rm=cmo.createResourceManager('Trial') fo=rm.createFileOpen('Trial-FO') fo.createTrigger('Trial1000',1000,'shutdown') fo.createTrigger('Trial700',700,'slow') fo.createTrigger('Trial500',500,'notify') cd('/ResourceManagement') cd(domainName) rm = cmo.createResourceManager('RestartPartition') rlp = rm.getRestartLoopProtection() rlp.setRestartLoopProtectionEnabled(true) rlp.setMaxRestartAllowed(3) rlp.setMaxRestartAllowedInterval(3600) rlp.setRestartDelay(10) fo = rm.createFileOpen('FileOpenQuota') fo.createTrigger('MaxFileOpenAllowed',20,'restart') save() activate() startEdit() cd('/Partitions') cd(partition-0) cmo.setResourceManagerRef(getMBean('/ResourceManagement/'+domainName+'/ResourceManager/Approved')) save() activate()
この項では、環境へのRCMの実装時に便利な追加情報を示します。
ガベージファースト(G1)ガベージ・コレクタはサーバー形式のガベージ・コレクタで、大容量のメモリーを搭載するマルチプロセッサ・マシンを対象としています。ガベージ・コレクション一時停止時間目標を高い確率で満たしながら、高いスループットを実現します。詳細は、http://docs.oracle.com/javase/8/docs/technotes/guides/vm/G1.html
を参照してください。
共在するアプリケーションのリソースの分離と管理を提供するその他のWebLogic Server機能は、次のとおりです。
クラス・ローダー・ベースの分離: アプリケーションの共有ライブラリに属していないクラスは、相互に分離されます。詳細は、「共有アプリケーション・クラス・ローダーの構成」および『Oracle WebLogic Serverアプリケーションの開発』のWebLogic Serverアプリケーションのクラスローディングの理解に関する項を参照してください。
WebLogic Serverワーク・マネージャ: 一連のスケジューリング・ガイドラインを構成して、処理の実行を優先度付けします。これにより、ワーク・マネージャは、アプリケーションに割り当てられているスレッドを管理し、それらのスレッドに対するワーク・マネージャ・インスタンスのスケジューリングを管理して、サービス・レベル合意に準拠できるようになります。詳細は、「パーティション・ワーク・マネージャの構成」および『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください
詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のマルチテナントのチューニングの推奨事項に関する項を参照してください。