legacy-knowledge-base
公開されました Jun. 30, 2025

Liferay PaaS のメモリ メトリックが Liferay DXP と異なる理由

投稿者

Michael Wall

knowledge-article-header-disclaimer-how-to

knowledge-article-header-disclaimer

legacy-article

learn-legacy-article-disclaimer-text
注:Liferay は、Liferay Experience Could オファリングの名称を次のように変更しました。 Liferay SaaS(旧 LXC) と Liferay PaaS(旧 LXC-SM)となりました。

問題

  • Liferay PaaSで表示されるLiferayサービスのメモリメトリクスが、Liferay DXPで表示されるものと異なる理由を説明します

環境

  • Liferay PaaS

 解決

コンテキスト:Liferay サービスメモリの設定

Dockerコンテナで利用可能な合計メモリ(MB単位)は、LiferayサービスのLCP.jsonの「memory」値によって設定されます。例:

"memory": 16384

JVMのヒープメモリは通常、LiferayサービスLCP.jsonのLIFERAY_JVM_OPTS、または同等の環境変数で、例えば-Xmsと-Xmxフラグを使って設定します。例:

-Xms4096m

-Xmx12288m

-XX:MaxMetaspaceSize=1024m

-XX:MetaspaceSize=1024m

-XX:NewSize=1536m

-XX:MaxNewSize=1536m

等。

推奨される構成は、-Xmsフラグを使用可能メモリ(MB単位)の25%に設定し、-Xmxフラグを使用可能メモリ(MB単位)の75%に設定することです。詳細については、こちらをご参照ください。 これは、オートスケーリングが有効かどうかにかかわらず適用されます。 こちらをご参照ください。

メタスペース・メモリは、JVMヒープ・メモリに追加されることに注意してほしい。

上記のスニペットは一例であり、推奨するものではありません。JVM オプションとパフォーマンス チューニングの詳細については、適切な Liferay DXP デプロイメント チェックリスト (DXP 7.4はこちら、DXP 7.3 はこちら、DXP 7.2 はこちら) をご参照ください。

Liferay DXP Memory MetricsはJVMヒープメモリに基づく

Liferay DXP > サーバ管理 > リソースタブのグラフとメトリクスはJVMのヒープメモリだけに基づいています。

計算方法は以下の通りです:

Runtime runtime = Runtime.getRuntime();

long totalMemory = runtime.totalMemory();

long usedMemory = totalMemory - runtime.freeMemory();

long maximumMemory = runtime.maxMemory();

out.println("Used Memory: " + usedMemory + " Bytes");

out.println("Total Memory: " + totalMemory + " Bytes");

out.println("Maximum Memory: " + maximumMemory + " Bytes");

注:上記のGroovyスクリプトは、サーバー管理 > スクリプト タブから実行できます。

場所:

  • Total Memoryは、JVMのヒープ・メモリの総量です。 このメソッドによって返される値は、通常、時間の経過とともに増加しますが、ガベージコレクションによって空きメモリが増加した後でも、一般的に減少することはありません。
  • 使用メモリ(Used Memory)とは、合計メモリ(Total Memory)からJVMの空きヒープ・メモリ(Free Heap Memory)を差し引いたものです。 これは、例えばガベージコレクションの後に増えたり減ったりしまし。 空きメモリはJVMが使用できますが、まだJVMに割り当てられているため、コンテナには解放されていません。
  • 最大メモリは、JVMが使用しようとするヒープ・メモリの最大量、つまりJVMに対して定義された-Xmx値である。

要約すると、ガベージコレクションをトリガーすることで、「空きメモリ」は増え、「使用メモリ」は減るかもしれませんが、「総メモリ」は必ずしも変わりません。

こちらをご参照ください。

Liferay DXP Cloud Console Memory Metrics はコンテナのメモリ使用量に基づいています。

Liferay Cloud Console > Monitoring のチャートとメトリクスは、Docker コンテナのメモリ使用量に基づいています。 https://cloud.google.com/monitoring/api/metrics_kubernetes > container/memory/used_bytes から、'non-evictable' memory、つまりカーネルが簡単に再利用できないメモリをフィルタリングしています。

Liferayサービスの場合、メモリ使用量には以下が含まれます:

  • JVMヒープメモリ(JVMの総メモリー量)
  • JVMの非ヒープメモリ(メタスペース、スレッド、GCなど)
  • コンテナが使用するJVM以外のメモリ

JVMの非ヒープメモリの詳細については、こちらこちらを参照ください。

追加情報

  • Liferay DXP Cloud Console > Liferay Service > Shell から実行される 'free -m' コマンドの出力はホストマシンのものであり、Docker コンテナのものではないので、このコンテキストでは意味がありません。
  • マルチノード環境では、Liferay Cloud Consoleは各ノードのメモリ使用量を表示しますが、Liferay DXP Resourcesのメトリクスは現在のノードのみです。
  • Liferay PaaS のメモリに関するリアルタイムアラートは、コンテナのメモリ使用量、定義されたクォータ、および DXP クラウドコンソールユーザーのアラート設定に基づいています。 デフォルトのメモリクォータは80%。 こちら こちらそして こちらをご参照ください。
  • Liferay PaaSのオートスケーリングは、LCP.jsonで定義された目標平均利用率に対するコンテナの平均メモリ(および平均CPU)利用率に基づいています。こちらをご参照ください。
  • サポートされている/推奨されている JDK バージョンと適切な Liferay DXP 7.x 互換性マトリックスについては、こちらをご覧ください。

「Java JDK 8ランタイムとの互換性はQ4.2023で廃止されました(これはDXPの以前のバージョンには適用されません)。 現在ではJava JDK 11が推奨ランタイム環境となっている。"

  • Liferay PaaS でスレッド ダンプとヒープ ダンプを作成する手順については、こちらをご参照ください。
  • より高度なモニタリングが必要な場合、Liferayは以下のようなアプリケーションパフォーマンスモニタリング(APM)ツールの使用を推奨します:
    • Glowrootは、Liferay DXP 2023.Q4 Quarterly Release 以降に含まれています。 Glowroot は、すべての環境で Liferay PaaS Liferay サービスに設定できます。
    • Dynatraceは、高可用性(HA)本番環境のLiferay PaaS Liferayサービスに設定できます。 詳しくはアカウント・マネージャーにお問い合わせください。
did-this-article-resolve-your-issue

legacy-knowledge-base