web-dev-qa-db-fra.com

mémoire du pod kubernetes - Java gc logs

Sur le tableau de bord kubernetes, il y a un pod dans lequel l'utilisation de la mémoire (octets) est affichée sous la forme 904.38Mi.

Ce pod contient l'application Java qui a été exécutée avec -Xms512m -Xmx1024m, et sur le fichier de déploiement kubernetes -> requests.memory = 512M, limits.memory = 1.5G.

J'ai activé les journaux gc et je les ai vus sur les journaux du pod:

[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

Comment Kubernetes est-il arrivé à 904.38Mi utilisation? Si j'ai bien compris, les usages actuels sont uniquement:

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

L'exécution de ps montre qu'il n'y a pas d'autres processus en cours d'exécution sur le pod en dehors de cette Java app.
Quelqu'un peut-il faire la lumière à ce sujet?

(modifié) Lorsque le pod a démarré et laissé fonctionner pendant quelques minutes, l'utilisation de la mémoire est affichée à environ 500 Mo seulement, puis laissez les demandes entrer, elle éclatera à 900 Mo-1 Go, puis lorsque tout aura été traité, l'utilisation de la mémoire sur Le tableau de bord k8s ne descend pas en dessous de 900 Mo, même si basé sur les journaux GC, le tas est GC ok.

javakubernetesmemory-managementgarbage-collectionkubernetes-metrics
5
villager

GC traite d'un sous-ensemble de mémoire utilisé par le processus. Certaines régions de la mémoire JVM ne sont pas soumises au garbage collection.

Voici quelques zones de mémoire non incluses dans le tas/métaspace

  • Espace de pile de threads
  • Espace de classe compressé
  • Code compilé JIT
  • Mémoire tampon directe NIO

La liste ci-dessus n'est pas complète, ce ne sont que les plus gros consommateurs de mémoire.

Voici le diagramme de hiérarchie de la mémoire JVM avec les options de configuration associées.

En résumé, l'appétit réel de la mémoire JVM est toujours supérieur à la limite du tas.

Le montant dépend de la nature de l'application et pourrait être établi empiriquement.

METTRE À JOUR

Java Native Memory Tracking pourrait être activé dans JVM pour fournir des rapports détaillés liés à l'utilisation de la mémoire dans différents domaines fonctionnels.

1
Alexey Ragozin