Est-ce que -XX:MaxRAMFraction1 est sûr pour la production dans un environnement conteneurisé?

Question

Java 8/9 a apporté son soutien pour l' -XX:+UseCGroupMemoryLimitForHeap (avec -XX:+UnlockExperimentalVMOptions). Ce jeux, -XX:MaxRAM de la cgroup limite de mémoire. Par défaut, la JVM alloue environ 25% de la RAM max, car -XX:MaxRAMFraction 4 par défaut.

Exemple:

MaxRAM = 1g
MaxRAMFraction = 4
JVM is allowed to allocate: MaxRAM / MaxRAMFraction = 1g / 4 = 256m

À l'aide de seulement 25% du quota semble comme des déchets pour un déploiement qui (généralement) se compose d'un unique processus de JVM. Alors maintenant, les gens se fixent -XX:MaxRAMFraction=1, de sorte que la JVM est théoriquement autorisé à utiliser 100% de l'MaxRAM.

Pour le 1g exemple, cela se traduit souvent dans les tailles de tas autour de 900m. Cela semble un peu élevé - il n'y a pas beaucoup de place libre pour la JVM ou d'autres choses comme la distance des coquilles ou des tâches de processus.

Est ce que cette configuration (-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction=1) considérés comme sûrs pour la prod ou même les meilleures pratiques? Ou dois-je encore ramasser -Xmx, -Xms, -Xss et ainsi de suite?

Answer 1

Nous avons fait quelques tests simples qui ont montré que le paramètre -XX:MaxRAM=$QUOTA et -XX:MaxRAMFraction=1 résultats tués dans les conteneurs sous charge. La JVM alloue plus de 900M tas, ce qui est beaucoup trop. -XX:MaxRAMFraction=2 semble à l'abri(ish).

Gardez à l'esprit que vous voudrez peut-être laisser de la marge pour d'autres processus, comme l'obtention d'un shell de débogage (docker exec) ou les tests de diagnostic dans le conteneur.

---

Edit: nous avons écrit ce que nous avons appris en détail dans un article. L'argent citations:

TL'DR: Java de gestion de la mémoire et de la configuration est toujours complexe. Bien que la JVM peut lire cgroup les limites de la mémoire et d'adapter l'utilisation de la mémoire en conséquence depuis Java 9/8u131, ce n'est pas un golden bullet. Vous avez besoin de savoir ce qu' -XX:+UseCGroupMemoryLimitForHeap t et vous avez besoin d'affiner certains paramètres pour chaque déploiement. Sinon, vous risquez de perdre des ressources et de l'argent ou d'obtenir vos contenants tué au pire moment possible. -XX:MaxRAMFraction=1 est particulièrement dangereux. Java 10+ apporte beaucoup d'améliorations, mais a encore besoin d'une configuration manuelle. Pour être sûr, test de charge de votre stuff.

et

La solution la plus élégante est de mettre à jour Java 10+. Java 10 dénonçait -XX:+UseCGroupMemoryLimitForHeap (11) et introduit, -XX:+UseContainerSupport (12), qui le remplace. Il introduit également -XX:MaxRAMPercentage (13) qui prend une valeur entre 0 et 100. Cela permet un contrôle précis de la quantité de RAM de la JVM est autorisé à allouer. Depuis +UseContainerSupport est activé par défaut, tout devrait fonctionner hors de la boîte.

---

Edit #2: nous avons écrit un peu plus à propos de -XX:+UseContainerSupport

Java 10 introduits +UseContainerSupport (activé par défaut) ce qui rend la JVM utilisation des valeurs par défaut saines dans un récipient contenant de l'environnement. Cette fonctionnalité est portée vers Java 8 depuis 8u191, permettant potentiellement un énorme pourcentage de Java déploiements dans la nature pour configurer correctement leur mémoire.

Answer 2

La récente oracle jdk-8(8u191) apporte les options suivantes pour permettre aux utilisateurs de conteneurs Docker pour gagner plus de contrôle de précision sur la quantité de mémoire système qui sera utilisé pour le Segment Java:

-XX:InitialRAMPercentage
-XX:MaxRAMPercentage
-XX:MinRAMPercentage

Trois nouveaux JVM options ont été ajoutées pour permettre aux utilisateurs de conteneurs Docker pour obtenir plus de précision, de contrôle sur la quantité de mémoire système qui sera utilisé pour le Segment Java:

-XX:InitialRAMPercentage -XX:MaxRAMPercentage -XX:MinRAMPercentage Ces options remplacer l'obsolète Fraction formes (-XX:InitialRAMFraction, -XX:MaxRAMFraction, et -XX:MinRAMFraction).

Voir https://www.oracle.com/technetwork/java/javase/8u191-relnotes-5032181.html