リソース消費管理の構成

リソース消費管理の構成: 概要

リソース消費管理(RCM)は、共有リソースを管理し、MT環境でドメイン・パーティションの一貫したパフォーマンスを提供するために、WebLogic Serverシステム管理者に柔軟性のある動的なメカニズムを提供します。

RCMポリシーは、リソース・マネージャとして構成されます。ドメイン・レベルのグローバル・スコープでリソース・マネージャを作成して、ドメイン内の任意のパーティションに対してRCMポリシーとして使用できます。パーティションにそのパーティションに固有のRCM特性がある場合は、パーティション・スコープのリソース・マネージャを作成することもできます。「リソース消費管理の構成: 主なステップ」を参照してください。

RCMを使用するためのソフトウェア要件

RCMには、Oracle Java Development Kit (JDK) 8u60ビルド32以降が必要です。

リソース消費管理が必要な理由

アプリケーションが複数のドメイン・パーティションにデプロイされた場合、低レベルのリソース(CPU、ヒープ、ネットワーク、ファイル・ディスクリプタなど)を共有すると、リソース割当てが不公平になる可能性があります。高トラフィック、アプリケーション設計、悪質なコードなどの様々な理由により、異常なリソース消費のリクエストが発生する可能性があります。これらのリクエスト・タイプにより、別に配置されたドメイン・パーティションがリソースにアクセスしないように、共有リソースの容量が過負荷となります。ドメイン・パーティション・レベルで適切なRCMポリシーを使用することによって、リソース消費管理は、あるパーティションのアプリケーションが他のパーティションのアプリケーションに悪影響を及ぼさないようにします。

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リソースの保護に関する項を参照してください。

RCMのサポートされるリソース

次の共有リソースは、RCMポリシーで管理できます。

FileOpen: パーティションで使用中の開いているファイル・ディスクリプタの数。これには、FileInputStream、FileOutputstream、RandomAccessFileおよびNIO Fileのチャネルを介して開いているファイルが含まれます。
HeapRetained: パーティションで保存される/使用中のヒープの量(MB)。
CpuUtilization: WebLogic Serverプロセスの使用可能なCPU時間に対する、パーティションで使用されるCPU時間の割合。

リソース消費管理の構成: 主なステップ

システム管理者は、リソース・マネージャを使用して、ドメインのパーティションごとに共有リソースに対するリソース消費管理ポリシーを指定します。リソース・マネージャは、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>
 
        
      <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>
 
    <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の例

config.xmlでのRCMの構成例

次の例は、「リソース消費管理の構成: 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>

リソース・マネージャの動的再構成

ドメイン・パーティションから、リソース管理ポリシーを動的に適用または削除できます。リソース管理ポリシーへの変更は、そのポリシーを使用するすべてのドメイン・パーティションに適用されます。

アクティブなドメイン・パーティションのポリシー更新が、リソースの現在の使用量より低いリソースに対してトリガー値を設定した場合、そのリソースのその後の使用量には、ポリシーのリコース・アクションが適用されています。ポリシーを変更すると、現在の使用量の値に基づいてアクティブなドメイン・パーティションが即時停止される場合、その変更は、動的再構成の変更として受け入れられません。

リソース消費管理の構成: リソース使用量のモニタリング

リソース消費管理メトリックを使用して、パーティションでの現在のリソース使用量をモニターし、パーティションのリソース消費をプロファイルおよび分析して、有効なリソース・マネージャとWLDFウォッチおよび通知を作成するために必要な、代表的な負荷、ピーク負荷、ピーク負荷時間などのデータを生成します。パーティション内の共有リソースのRCMメトリックは、PartitionResourceMetricsRuntimeMBeanを介して使用可能になります。

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ポリシーを使用します。これらのポリシーにより、既存のドメインに対するパーティションRCMポリシーのインポートおよびエクスポートが容易になります。

リソース管理ポリシーがパーティションで明示的に設定されていない場合、そのパーティションの使用可能な共有リソースへのアクセスには制約がありません。

CPU使用率の管理

CPU使用率は、配置されたドメイン・パーティションによってCPUの競合を追跡する優れたメトリックで、CPUバインドされたワークロードのフェア・シェア・ポリシーで特に役立ちます。CPU使用率を最大化するためにRCMポリシーを使用する場合は、次のことを考慮します。

ドメイン内のすべてのパーティションのワークロード(統合ワークロード)を考慮したときに、CPUのピーク使用率がCPUの平均使用率を大きく超えないようにする必要があります。CPUのピーク負荷とCPUの平均負荷の差を最小化すると、ドメインのCPU使用率を最大化できます。
CPU使用率の約75%がドメインのパーティションに格納されたアプリケーションに使用されるようにRCMのCPUポリシーを構成することをお薦めします。残りの25%の10%ほどは操作タスク(バックアップ、スケジュール済タスクおよびその他の管理)に、15%ほどはクラスタ・フェイルオーバーに割り当てる必要があります。

ヒープの管理

ドメインおよびその他のシステム・ワークに十分な量の使用可能なヒープ(ヘッドルーム)を提供し続けながら、パーティションのアプリケーションの要件をサポートするメモリー使用プランを作成します。ドメインのヒープ要件を評価する際に、各パーティションの代表的なワークロードの低、平均、安定した状態およびピークのHeap Retainedの使用量の値を考慮します。

RCMの制限事項

RCMには、注意が必要な一定の制限事項があります。

ヒープ・リソース消費の追跡および管理は、G1ガベージ・コレクタで実行される場合のみサポートされます(他のJDKコレクタではRCMはサポートされません)。
JNI/ネイティブ・コードで発生するアクティビティのリソース消費メトリックの測定および計上はサポートされていません。
保持されるヒープとCPU使用率の測定は非同期的に実行されるため、現在の(ポイント・イン・タイムの)値を表しません。
静的フィールド内のオブジェクトのヒープ使用状況の区別、およびシステムからロードされたクラスおよび共有クラス・ローダーのシングルトン・オブジェクトに問題があり、最終会計値で正確に表されない可能性があります。システムからロードされたクラスおよび共有クラス・ローダーのインスタンスがパーティションによってロードされた場合、インスタンスのヒープの使用がそのパーティションに対して計上されます。
ガベージ・コレクション・アクティビティは、Oracle JDK 8u40を使用したWebLogic Server 12.2.1の特定のドメイン・パーティションに分離されません。
サーバー・インスタンスでリソース消費の追加の追跡および管理が発生するため、RCM機能を有効にする際にパフォーマンスへの悪影響があります。

リソース消費管理の構成: WLSTの例

WLSTを使用して、RCMポリシーを実装およびモニターできます。

RCMのWLSTの例: 概要

次に、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スクリプト

「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のパフォーマンスのチューニング』のマルチテナントのチューニングの推奨事項に関する項を参照してください。