web-dev-qa-db-ja.com

kubernetesポッドメモリ-Java gcログ

Kubernetesダッシュボードに、メモリ使用量（バイト）が904.38Miと表示されるポッドがあります。

このポッドは、-Xms512m -Xmx1024mを使用して、およびkubernetesデプロイメントファイル-> requests.memory = 512M、limits.memory = 1.5Gで実行されたJavaアプリを保持します。

私はgcログを有効にしており、ポッドログでこれらを確認しています：

[2020-04-29T15:41:32.051+0000] GC(1533) Phase 1: Mark live objects
[2020-04-29T15:41:32.133+0000] GC(1533) Phase 1: Mark live objects 81.782ms
[2020-04-29T15:41:32.133+0000] GC(1533) Phase 2: Compute new object addresses
[2020-04-29T15:41:32.145+0000] GC(1533) Phase 2: Compute new object addresses 11.235ms
[2020-04-29T15:41:32.145+0000] GC(1533) Phase 3: Adjust pointers
[2020-04-29T15:41:32.199+0000] GC(1533) Phase 3: Adjust pointers 54.559ms
[2020-04-29T15:41:32.199+0000] GC(1533) Phase 4: Move objects
[2020-04-29T15:41:32.222+0000] GC(1533) Phase 4: Move objects 22.406ms
[2020-04-29T15:41:32.222+0000] GC(1533) Pause Full (Allocation Failure) 510M->127M(680M) 171.359ms
[2020-04-29T15:41:32.222+0000] GC(1532) DefNew: 195639K->0K(195840K)
[2020-04-29T15:41:32.222+0000] GC(1532) Tenured: 422769K->130230K(500700K)
[2020-04-29T15:41:32.222+0000] GC(1532) Metaspace: 88938K->88938K(1130496K)
[2020-04-29T15:41:32.228+0000] GC(1532) Pause Young (Allocation Failure) 603M->127M(614M) 259.018ms
[2020-04-29T15:41:32.228+0000] GC(1532) User=0.22s Sys=0.05s Real=0.26s

Kubernetesはどのように904.38Miの使用に達しましたか？私が正しく理解した場合、現在の使用法は次のとおりです。

DefNew (young) -      0k
Tenured        - 130230K
Metaspace      -  88938K
Sum            - 216168K

psを実行すると、このJavaアプリ以外に、ポッドで実行されている他のプロセスがないことを示します。
誰でもこれに光を当てることができますか？

（編集）ポッドが最初に起動して数分間実行されると、メモリ使用量は約500 MBとしてのみ表示され、次にリクエストがそこに到着すると900 MB-1 GBにバーストし、すべてが処理されるとメモリ使用量がk8sダッシュボードは、GCログに基づいていても、ヒープはGCで問題なくても、900 MB未満にはなりません。

javakubernetesmemory-managementgarbage-collectionkubernetes-metrics
5
villager

GCは、プロセスが使用するメモリのサブセットを扱います。ガベージコレクションの対象とならないJVMメモリの領域があります。

以下は、ヒープ/メタスペースに含まれていないいくつかのメモリ領域です

  • スレッドスタックスペース
  • 圧縮クラススペース
  • JITコンパイル済みコード
  • NIOダイレクトバッファーメモリ

上記のリストは完全ではありません。これらは単なる最大のメモリ消費量です。

JVMメモリー階層図 関連する構成オプション.

要約すると、実際のJVMメモリ食欲は常にヒープ制限よりも大きくなります。

どれだけ大きいかは、アプリケーションの性質に依存し、経験的に確立することができます。

更新

Java Native Memory Tracking は、JVMで有効にして、さまざまな機能領域にわたるメモリ使用量に関する詳細レポートを提供できます。

1
Alexey Ragozin