WebLogic ServerポッドのCPUおよびメモリーのリクエストおよび制限は、通常、ワークロード、アプリケーションおよびKubernetes環境によって最適な値が異なる場合にチューニングする必要があります。 リクエストおよび制限は、ピーク使用量時に予想されるトラフィックに基づいて構成する必要があります。 例えば:
要件は、ユースケースによって異なります。 環境内のリソース使用状況のモニタリングに基づいて、実験および調整が必要になる場合があります。
オペレータは、各ドメインのWebLogic ServerインスタンスおよびWebLogic Serverポッドの起動前に自動的に起動される短期間のイントロスペクタ・ジョブに対して、独自のポッドにコンテナを作成します。 Kubernetesリソースのリクエストおよび制限を構成してコンテナ・メモリーおよびCPU使用率をチューニングし、ドメインYAMLファイルのUSER_MEM_ARGS環境変数を使用してWebLogic JVMヒープ使用率をチューニングできます。 デフォルトでは、イントロスペクタ・ジョブ・ポッドは、ドメインのWebLogic管理サーバー・ポッドと同じCPUおよびメモリー設定を使用します。 同様に、オペレータが「補助イメージ」ベースのドメインのイントロスペクタ・ジョブ・ポッドにinitコンテナを作成した場合、ドメインのWebLogic管理サーバー・ポッドと同じCPUおよびメモリー設定が使用されます。 domain.spec.introspector.serverPod要素を使用して、イントロスペクタ・ジョブ・ポッドの設定をオーバーライドできます。 リソース・リクエストは、コンテナが必要とするリソースの最小量を設定します。 リソース制限は、コンテナに割り当てられるリソースの最大量であり、コンテナがリソースの共有を超えて使用することを防ぎます。 さらに、リソース・リクエストおよび制限によってポッドのサービス品質が決まります。
このFAQでは、WebLogic Serverインスタンスを効率的に実行するためのこれらのパラメータのチューニングについて説明します。
KubernetesメモリーおよびCPUリクエストおよび制限は、domain.spec.serverPod.resourcesスタンザを使用して「ドメインまたはクラスタのYAMLファイル」に設定でき、domain.spec.adminServerまたはdomain.spec.managedServersのserverPod.resources要素を使用して個々のWebLogic Serverインスタンスの設定をオーバーライドできます。 cluster.spec.serverPod要素を使用して、クラスタのメンバー・サーバーの設定をオーバーライドできます。 イントロスペクタ・ジョブ・ポッドは、WebLogic管理サーバー・ポッドと同じ設定を使用します。 domain.spec.introspector.serverPod要素を使用して、イントロスペクタ・ジョブ・ポッドの設定をオーバーライドできます。
.serverPodスタンザに設定した値は、より具体的なポッド・タイプに対して設定され、より一般的なポッド・タイプにも設定されている場合は同じ値をオーバーライドし、より一般的なポッドに設定された他の値を継承します。 domain.spec.adminServer.serverPod、domain.spec.managedServers.serverPodおよびcluster.spec.serverPodスタンザはすべて、domain.spec.serverPodスタンザから継承され、オーバーライドされます。 domain.spec.managedServers.serverPodスタンザがクラスタの一部であるポッドを参照する場合、クラスタのcluster.spec.serverPod設定(ある場合)から継承され、オーバーライドされます。これにより、ドメインのdomain.spec.serverPod設定から継承され、オーバーライドされます。
spec:
serverPod:
resources:
requests:
cpu: "250m"
memory: "768Mi"
limits:
cpu: "2"
memory: "2Gi"
CPUリソースの制限およびリクエストは、CPU単位で測定されます。 Kubernetesの1 CPUは、クラウド・プロバイダの場合は1 vCPU/Core、ベアメタルIntelプロセッサの場合は1ハイ・パー・スレッドと同等です。 CPU属性のmサフィクスはミリCPUを示すため、250mはCPUの25%です。
メモリーはさまざまな単位で表現できます。ここで、Miは1つのIECユニット・メガバイト(1024 ^ 2)で、Giは1つのIECユニット・ギガバイト(1024 ^ 3)です。
Kubernetesドキュメントの「コンテナのリソースの管理」、「コンテナおよびポッドへのメモリー・リソースの割当て」および「コンテナおよびポッドへのCPUリソースの割当て」も参照してください。
ポッドのサービスのクオリティ(QoS)は、リソース・リクエストおよび制限付きで構成されているかどうかに基づきます:
「ベスト・エフォートQoS」 (最低優先度): ポッドのリクエストおよび制限を構成しない場合、ポッドにはbest-effort QoSが付与されます。 ノードで共有不可能なリソースが不足している場合は、デフォルトのリソース不足削除ポリシーによって、最初にbest-effort QoSで実行中のポッドが削除されます。
Burstable QoS (中優先度): ポッドのリソース・リクエストと制限の両方を構成し、リクエストがそれぞれの制限を下回るように設定すると、ポッドにburstable QoSが付与されます。 同様に、ポッドのリソース・リクエストのみを(制限なしで)構成する場合、ポッドQoSもburstableになります。 ノードで共有不可能なリソースが不足した場合、ノードのkubeletは、実行中のbest-effortポッドがなくなったときにのみburstableポッドを除去します。
「保証付きQoS」 (最高の優先度): ポッド・リクエストと制限を同じ値に設定すると、ポッドにはguaranteed QoSが設定されます。 これらの設定は、ポッドが一定量のメモリーとCPUを消費することを示します。 この構成では、ノードで共有可能なリソースが不足した場合、guaranteed QoSポッドを終了する前に、ノードのkubeletによってbest-effortおよびburstable QoSポッドが削除されます。
ほとんどのユース・ケースでは、Oracleでは、メモリーおよびCPUリクエストと制限を使用してWebLogicポッドを構成し、さらにguaranteed QoSを確保するために、それぞれの制限に等しいリクエストを設定することをお薦めします。
Kubernetesの新しいバージョンでは、「ポッド優先度先制」をserverPod.priorityClassNameドメイン・フィールドと組み合せて使用して、スケジュールおよび削除ポリシーを微調整できます。 Kubernetesには、すでに2つのPriorityClassesが付属しています: system-cluster-criticalおよびsystem-node-critical。 これらは共通クラスであり、「重要なコンポーネントが常に最初にスケジュールされるようにします」で使用されます。
Oracleは、デフォルトに依存するのではなく、WebLogic JVMのJavaヒープ・サイズを構成することをお薦めします。 WLSサーバーが実行されているポッドからWLSTを実行する際のメモリー設定の詳細は、「kubectl execの使用」を参照してください。
WebLogic JVMおよびポッドの正しいヒープ・サイズ、メモリー・リクエストおよびメモリー制限を設定することが非常に重要です。
WebLogic JVMヒープは、そのアプリケーションおよびサービスを実行するのに十分なサイズにする必要がありますが、メモリー・リソースを浪費しないように大きさを変更しないでください。
ポッド・メモリー制限は、構成されたヒープおよびネイティブ・メモリー要件に対応するのに十分なサイズにする必要がありますが、メモリー・リソースを浪費しないように大きさを変更しないでください。 JVMのメモリー使用量(ヒープとネイティブ・メモリーの合計)がポッドの制限を超えると、メモリー不足エラーのためにJVMプロセスが突然強制終了され、その結果、WebLogicコンテナはリブネス・プローブの失敗によって自動的に再起動します。
Oracleは、最小ヒープと最大ヒープ(またはヒープ率)および少なくともコンテナ・メモリー・リクエストを設定することをお薦めします。
リソース・リクエストおよびリソース制限の設定が高すぎると、ノード・リソースが不足しているためにポッドがスケジュールされない場合があります。 他のポッドで使用できるCPU共有リソースを不必要に使用するか、他のポッドの実行を妨げる可能性があります。
最新のJavaバージョン、Java 8更新191以降またはJava 11では、ヒープ・サイズを構成しない場合(-Xmsまたは-Xmsなし)、デフォルトのヒープ・サイズは動的に決定されます:
コンテナのメモリー制限を構成すると、JVMのデフォルトの最大ヒープ・サイズはコンテナ・メモリー制限の25% (1/4)になり、デフォルトの最小ヒープ・サイズは制限値の1.56% (1/64)になります。
この場合、WebLogic JVMがコンテナで実行されている唯一の主要なプロセスであるため、デフォルトのJVMヒープ設定は保守的すぎることがよくあります。
メモリー制限が構成されていない場合、JVMのデフォルトの最大ヒープ・サイズはノードのマシンRAMの25% (1/4)になり、デフォルトの最小ヒープ・サイズはRAMの1.56% (1/64)になります。
この場合、デフォルトのJVMヒープ設定は、同じノードで実行される他のポッドに影響を与える可能性のある時点までの不要なメモリー量の使用など、望ましくない動作をする可能性があります。
ポッド・メモリー制限を指定した場合、OracleではWebLogic Serverヒープ・サイズを割合として構成することをお薦めします。 JVMは、割合を制限の割合として解釈します。 これは、USER_MEM_ARGS 「ドメイン環境変数」のJVM -XX:InitialRAMPercentageおよび-XX:MaxRAMPercentageオプションを使用して行います。 例えば:
spec:
resources:
env:
- name: USER_MEM_ARGS
value: "-XX:InitialRAMPercentage=25.0 -XX:MaxRAMPercentage=50.0 -Djava.security.egd=file:/dev/./urandom"
また、独自のヒープおよびネイティブ・メモリー要件を持つWebLogic Serverと同じコンテナで実行されているnode-managerプロセスがあります。 そのヒープは、NODEMGR_MEM_ARGS環境変数で-Xmsおよび-Xmxを使用してチューニングされます。 Oracleは、ノード・マネージャのヒープ・メモリーをパーセンテージではなく固定サイズに設定することをお薦めします。通常は、「デフォルトのチューニング」で十分です。
NODEMGR_MEM_ARGS、USER_MEM_ARGSおよびWLST_EXTRA_PROPERTIES環境変数はすべて、デフォルトで-Djava.security.egd=file:/dev/./urandomを含むことに注意してください。 これにより、エントロピが低いシステムではノード・マネージャおよびWebLogic Serverの起動を高速化するとともに、WLST encryptコマンドのイントロスペクション・ジョブの使用を高速化するのに役立ちます。 この速度を維持するためにカスタムのUSER_MEM_ARGS値を指定するために、このプロパティを前述の例に含めました。 詳細は、「環境変数のデフォルト」のドキュメントを参照してください。
場合によっては、メモリー・リソース・リクエストのみを構成し、メモリー・リソース制限は構成しない方がよいことがあります。 このようなシナリオでは、パーセント設定(-XX:InitialRAMPercentageおよび-XX:MaxRAMPercentage)のかわりに、WebLogic Server USER_MEM_ARGSで従来の固定ヒープ・サイズ設定(-Xmsおよび-Xmx)を使用できます。
WebLogic ServerポッドのCPUリクエストと制限の両方を設定することが重要です。 これにより、すべてのWebLogic Serverポッドに十分なCPUリソースが確保され、前述のように、リクエストと制限が同じ値に設定されている場合は、guaranteed QoSが取得されます。 guaranteed QoSでは、スケジューリング中にポッドがより高い優先度で処理されることが保証されるため、最も削除される可能性が低くなります。
WebLogic ServerポッドにCPUリクエストおよび制限が構成されて「いない」場合:
ポッドは、そのノードで使用可能なすべてのCPUリソースを使用して終了し、他のコンテナが共有可能なCPUサイクルを使用しないようにできます。
WebLogic Server JVMは、不適切なガベージ・コレクション(GC)戦略を選択する場合があります。
WebLogic Server自己チューニングwork-managerは、デフォルトのスレッド・プールに割り当てるスレッド数を誤って最適化する可能性があります。
最大ノードのコア数より大きいCPUコア数を設定した場合、ポッドはスケジュールされないことにも注意してください。 4つのコアを必要とするポッドがあり、2つのコアVMで構成されるKubernetesクラスタがあるとします。 この場合、ポッドはスケジュールされず、Pendingステータスになります。 例えば:
$ kubectl get pod sample-domain1-managed-server1 -n sample-domain1-ns
NAME READY STATUS RESTARTS AGE
sample-domain1-managed-server1 0/1 Pending 0 65s
$ kubectl describe pod sample-domain1-managed-server1 -n sample-domain1-ns
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 16s (x3 over 26s) default-scheduler 0/2 nodes are available: 2 Insufficient cpu.
オペレータ・サンプルでは、256MB以上および512MB以上のWebLogic Server JVMのデフォルト以外の最小ヒープ・サイズおよび最大ヒープ・サイズをそれぞれ構成します。 サンプルのテンプレート、ドメインまたはクラスタYAMLファイルresources.env USER_MEM_ARGSを編集して、異なる値を設定できます。 「ヒープ・サイズの構成」を参照してください。
同様に、オペレータ・サンプルでは、CPUおよびメモリー・リソース・リクエストをそれぞれ250mおよび768Mi以上に構成します。
サンプルではメモリーまたはCPUの制限がデフォルトで構成されていないため、サンプルのWebLogic ServerポッドのデフォルトのQoSはburstableです。
サンプル・ドメインまたはクラスタのYAMLファイルまたはテンプレートでリソース・リクエストまたは制限を異なる方法で設定する場合は、「ドメインまたはクラスタ・リソースでのリソース・リクエストおよび制限の設定」を参照してください。 または、入力YAMLファイルを使用してドメイン・リソースを生成するサンプルについては、サンプルのcreate-domain.sh入力ファイルのserverPodMemoryRequest, serverPodMemoryLimit, serverPodCpuRequestおよびserverPodCpuLimitパラメータを参照してください。
CPUリソース・リクエストを構成するがCPU制限を持たない「バースト可能なポッド」がある場合、JDKはアクティブ・プロセッサ数を誤って計算する可能性があります。 JDKでは、JDK-8288367で説明されているように、--cpu-sharesパラメータの値(spec.containers[].resources.requests.cpuにマップ)が解釈され、現在のプロセスで使用できるCPUの数が制限されます。 これにより、JVMは使用可能なCPUより少ないCPUを使用するため、Kubernetes環境で実行すると、CPUリソースの使用率が低下する可能性があります。 JDKを新しいバージョン(JDK 8u371またはJDK 11.0.17)に更新すると、これが修正されます。
JVMが様々なサブシステムのスレッドを作成するときに自動的に検出して使用するCPUの数をオーバーライドするには、-XX:ActiveProcessorCount Javaオプションを使用します。
KubernetesでホストされているWebLogic Serverは、オンプレミス・デプロイメントと比較してロックの競合が多い場合があります。 このロック競合は、異なるCPUコア間でワークロードが移動するときのCPUキャッシュ・アフィニティまたはスケジューリング待機時間の不足が原因である可能性があります。
オンプレミス・デプロイメントでは、(tasksetコマンドを使用して) WLS Javaプロセスを特定のCPUコアにバインドすることで、CPUキャッシュ・アフィニティを実現し、ロック競合を減らすことができます。
Kubernetesデプロイメントでは、次のようにして同様のキャッシュ・アフィニティを実現できます:
guaranteed QoSを確保するため)。kubelet CPUマネージャ・ポリシーをstaticに構成します(デフォルトはnone)。 「ノードでのCPU管理ポリシーの制御」を参照してください。 一部のKubernetes環境では、CPU管理ポリシーの変更が許可されない場合があります。 PrometheusおよびGrafanaを使用して、JVMヒープ、ポッドCPUおよびポッド・メモリーを監視できます。 また、Kubernetesドキュメントの「リソースをモニタリングするためのツール」も参照してください。