メモリの問題をトラブルシューティングするためのツール

この記事の適用対象: ✔️ Basic または Standard ✔️ Enterprise

この記事では、Java のメモリの問題を解決する際に役立つさまざまなツールについて説明します。 これらのツールは、メモリの問題に限らず多くのシナリオで使用できますが、この記事ではメモリのトピックのみに焦点を当てています。

アラートと診断

以降のセクションでは、Azure portal で使用できる Resource Health アラートと診断について説明します。

リソース ヘルス

Azure Activity ログと Azure Service Health で、アプリのライフサイクル イベントを監視したりアラートを設定したりできます。 詳細については、「Azure Activity ログと Azure Service Health で、アプリのライフサイクル イベントを監視する」を参照してください。

Resource Health は、コンテナーのメモリ不足 (OOM) の問題に起因するアプリの再起動イベントについてのアラートを送信します。 詳細については、「メモリ不足の問題によって引き起こされるアプリの再起動の問題」を参照してください。

次のスクリーンショットは、OOM の問題を示すアプリの Resource Health アラートを示しています。

問題の診断と解決

Azure Spring Apps 診断は、構成無しでアプリのトラブルシューティングが可能な対話型エクスペリエンスです。 詳細については、「Azure Spring Apps での問題の自己診断と解決」を参照してください。

次のスクリーンショットに示したように、Azure portal の [問題の診断と解決] に [メモリ使用量] があります。

次のスクリーンショットに示したように、[メモリ使用量] では、アプリのメモリ使用量に関する簡単な診断が利用できます。

メトリック

以降のセクションでは、メモリ使用量が多い、ヒープ メモリが大きすぎる、ガベージ コレクションに異常が見られる (頻度が多すぎる、少なすぎる) などの問題に関連したメトリックについて説明します。 詳細については、「クイックスタート: ログ、メトリック、トレースを使用した Azure Spring Apps アプリの監視」を参照してください。

アプリのメモリ使用量

アプリのメモリ使用量は、使用されているアプリ メモリをアプリ メモリの上限で除算して得られる割合 (%) です。 この値は、アプリ メモリ全体を表します。

jvm.memory.used/committed/max

JVM メモリには、以下の箇条書きで説明した jvm.memory.used、jvm.memory.committed、jvm.memory.max の 3 つのメトリックがあります。

"JVM メモリ" は明確に定義された概念ではありません。 ここで、jvm.memory は、かつて permGen と呼ばれていた非ヒープ メモリ領域とヒープ メモリとの合計です。 JVM メモリに、ダイレクト メモリやその他のメモリ (スレッド スタックなど) は含まれません。 Spring Boot アクチュエータは、これらの 3 つのメトリックを収集し、jvm.memory のスコープを決定します。

• jvm.memory.used は使用済み JVM メモリ量です。使用済みヒープ メモリのほか、非ヒープ メモリ内のかつて permGen と呼ばれていた領域の使用済み量が含まれます。

  jvm.memory.used に反映されるのはほとんどがヒープ メモリの変化です。かつての permGen 領域は通常不変であるためです。

  jvm.memory.used が大きすぎることが判明した場合は、ヒープ メモリの最大サイズをもっと小さくすることを検討してください。

• jvm.memory.committed は、JVM が使用するためにコミットされたメモリの量です。 jvm.memory.committed のサイズが、基本的に使用可能な JVM メモリの上限となります。

• jvm.memory.max は JVM メモリの最大量です。実際の使用可能な量と混同しないでください。

  jvm.memory.max の値は、使用可能なアプリ メモリよりもはるかに大きくなることがあるため、わかりにくい場合があります。 明確に言うと、jvm.memory.max は、ヒープ メモリの全領域の最大サイズと、非ヒープ メモリ内のかつての permGen 領域との合計であり、実際の使用可能メモリとは関係ありません。 たとえば、Azure Spring Apps ポータルでアプリが 1 GB のメモリで設定されている場合、ヒープ メモリの既定のサイズは 0.5 GB です。 詳細については、「Java のメモリ管理」の「既定の最大ヒープ サイズ」セクションを参照してください。

  既定の "圧縮クラス領域" のサイズが 1 GB の場合、アプリ メモリのサイズが 1 GB かどうかに関係なく、jvm.memory.max の値は 1.5 GB よりも大きくなります。 詳細については、Oracle ドキュメントの「Java Platform Standard Edition HotSpot Virtual Machine ガベージ コレクション チューニング ガイド」の「その他の考慮事項」を参照してください。

jvm.gc.memory.allocated/promoted

この 2 つのメトリックの目的は、Java ガベージ コレクション (GC) の観察です。 詳細については、「Java のメモリ管理」の「Java ガベージ コレクション」セクションを参照してください。 ヒープの最大サイズは、Minor GC と Full GC の頻度に影響します。 メタスペースとダイレクト メモリの最大サイズは、Full GC に影響します。 ガベージ コレクションの頻度を調整したい場合は、次の最大メモリ サイズの変更を検討してください。

• jvm.gc.memory.allocated は、ある GC から次の GC までの Young 世代のメモリ プール サイズの増加量です。 この値は Minor GC を反映します。

• jvm.gc.memory.promoted は、GC 後における Old 世代のメモリ プール サイズの増加量です。 この値は Full GC を反映します。

次のスクリーンショットに示したように、この機能は Azure portal で確認できます。 具体的なメトリックを選択したり、特定のアプリ、デプロイ、またはインスタンスのフィルターを追加したりできます。 分割を適用することもできます。

その他のデバッグ

さらに詳しくデバッグするには、ヒープ ダンプとスレッド ダンプを手動でキャプチャし、Java Flight Recorder (JFR) を使用します。 詳細については、「Azure Spring Apps でヒープ ダンプとスレッド ダンプを手動でキャプチャして Java Flight Recorder を使用する」を参照してください。

ヒープ ダンプには、Java のヒープ メモリの状態が記録されます。 スレッド ダンプには、すべてのライブ スレッドのスタックが記録されます。 これらのツールは Azure CLI から利用できるほか、次のスクリーンショットに示したように Azure portal のアプリ ページから利用することもできます。

詳細については、「Azure Spring Apps でヒープ ダンプとスレッド ダンプを手動でキャプチャして Java Flight Recorder を使用する」を参照してください。 Memory Analyzer などのサード パーティ ツールを使用してヒープ ダンプを分析することもできます。

構成変更によって問題を解決する

特定されうる問題としては、コンテナーの OOM、過大なヒープ メモリ、ガベージ コレクションの異常などが考えられます。 こうした問題のいずれかが特定された場合は、JVM オプションで最大メモリ サイズを構成する必要があります。 詳細については、「Java のメモリ管理」の「重要な JVM オプション」セクションを参照してください。

JVM オプションは、Azure portal または Azure CLI を使用して変更できます。

az spring app update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --app <app-name> \
    --deployment <deployment-name> \
    --jvm-options <jvm-options> \

関連項目

• Java のメモリ管理
• メモリ不足の問題によって引き起こされるアプリの再起動の問題