Nous avons dockerisé une application JVM (Scala), Java 1.7 et tente de décider comment allouer de la mémoire. Nous avons une seule application exécutée dans le conteneur Docker. Si le conteneur Docker est attribué 4 Go de RAM, devrions-nous allouer 4 Go (ou peut-être un peu moins juste pour être sûr) à la JVM?
Si je comprends bien, il n'y a pas d'autres processus qui fonctionnent à l'intérieur du conteneur Docker en plus de ce que l'on appelle à partir du point d'entrée, nous ne devrions donc pas avoir besoin de vous inquiéter de l'utilisation de la mémoire non-JVM - est-ce vrai, ou une simplification sur ? Y a-t-il d'autres questions que nous devrions poser?
edit Nous utilisons des mésos / marathon pour déployer les images Docker - je crois que cela définit les limites de Cgroup sur la mémoire (au moins, cela donne l'impression que cela le fait) mais je pourrais certainement être faux.
3 Réponses :
Aux fins de votre question, traitez votre conteneur comme un processus exécuté sur la machine hôte.
IT est un processus en cours d'exécution sur la machine hôte, bien que ses propres espaces de noms pour réseau, processus, etc.
Vous n'allez même pas "allouer" la mémoire à un conteneur; Vous pouvez LIMITER si vous aimez Via Cgroups, mais depuis que le JVM a sa propre limite, cela est inutile.
Enfin, dans cette situation, vous contrôlez une utilisation de la mémoire virtuelle, pas la RAM.
Nous utilisons Mesos / Marathon, alors je crois que cela limite la mémoire via des cgroups (bien que je puisse me tromper). À tout le moins, nous avons des attentes de mémoire pour les conteneurs Docker, car de nombreux conteneurs seront déployés côte à côte. Tous ajoutent des éclaircissements, mais je ne suis pas sûr que cela répond vraiment à ma question - s'il est limité, devrions-nous maximiser la mémoire Java à la limite de Cgroup?
J'ai le même scénario et j'utilise 90% de la mémoire réservée à JVM et travaille très bien
Merci d'avoir répondu! Nous faisons quelque chose de similaire, et cela fonctionne, mais je suis vraiment curieux des internaux - y a-t-il des frais généraux du conteneur lui-même qui feraient l'affectation de la mémoire
Laissant 90% de la mémoire réservée à Java est très risquée. Ma suggestion jusqu'à présent est de tester votre candidature et de voir la quantité de mémoire que la JVM prend. Gardez à l'esprit que la mémoire est signalée par le système d'exploitation, car elle peut être nettement supérieure à la mémoire que vous avez attribuée à la pile du tas + Perm Space + Threads. Juste pour vous donner une idée, nous cédions 75% de la mémoire du conteneur sur le tas. Ensuite, nous l'avons abaissé à 65% et enfin à 50% car Docker tue le conteneur en raison de la limite de mémoire. Avec 50%, nous étions bons. Cela signifie que si dans Docker, nous avons attribué 2G, JVM Heap était 1G (ceci est JDK 8).
Garder dans l'esprit des rapports seront différents selon l'application que vous utilisez. Par exemple, nous avons une application qui nécessite juste un petit tas, environ 64 m, cependant si nous créons un conteneur de docker avec 128 m, il sera tué à un moment donné en raison de limites de mémoire. Dans ce cas, nous avons dû attribuer 256 m au conteneur même lorsque l'application utilisait 64 m de tas. Comme je l'ai signalé dans mon commentaire précédent, vous devez probablement tester vos applications.
Voici un excellent article à ce sujet: plumbr.eu/blog/memory-leaks/.../a>
Vous ne pouvez pas donner -xmx la même valeur que la mémoire de conteneur, car Java aura besoin de plus d'espace pour la génération permanente (Permgen), le cache de code, etcetera. Il y a un outil pour un autre environnement de conteneurs, gardien. L'outil est ici : Je pense que cela peut également être utilisé à l'intérieur de Docker. Besoin de tester.