Dois-je mettre un MaxMetaspaceSize?
Donc, après avoir demandé question, il est rapidement devenu clair que la question importante n'est pas "comment", mais "je"?
nous avons des clients que nous déplaçons de Java7 à Java8 (en utilisant Tomcat7). Java7 nécessitait de définir le -XX:MaxPermSize,et certains clients ont augmenté leurs max au-dessus de la valeur par défaut définie par l'installateur en raison de besoins et d'utilisations individuels.
Devrais-Je mettez le -XX:MaxMetaspaceSize (à la précédente -XX:MaxPermSize réglage) pour les clients qui ont défini un max personnalisé? Et les nouvelles installations? Devrions-nous définir -XX:MaxMetaspaceSize?
Quels sont les avantages et les inconvénients d'une telle décision?
3 réponses
comme j'ai commenté sur la réponse précédente le justification pour fixer une limite sur ces pools de mémoire est différent.
si vos utilisateurs ont déjà augmentation de la le MaxPermSize au-dessus de la valeur par défaut qui était probablement soit d'éviter les échecs complets de GCS / mode concurrent avec CMS, soit parce que leurs applications nécessitaient vraiment beaucoup d'espace de génération de perm.
diminuer la limite de la métaspace par rapport à sa valeur par défaut effectivement infinie but différent: éviter la croissance illimitée de metaspace.
Le truc, c'est que c'est juste une limite supérieure. Le fait commis, c'est à dire la taille de la métaspace sera plus petite. En fait, il s'agit d'un paramètre appelé MaxMetaspaceFreeRatio (70% par défaut) ce qui signifie que la taille réelle de la métaspace ne dépassera jamais 230% de son occupation.
et pour qu'il pousse en premier il faudrait remplir, forçant une collecte des ordures (metaspace pleine) dans une tentative de libérer des objets et seulement lorsqu'il ne peut pas répondre à ses MinMetaspaceFreeRatio (par défaut 40%), l'objectif est d'étendre la métaspace pas plus de 230% de l'occupation après le cycle GC.
ainsi, dans la pratique, la taille réelle du métaspace devrait se stabiliser à l'intérieur d'une bande proche par rapport à son besoin réel, à moins que l'application ne fuit continuellement classloaders/classes ou ne génère une énorme quantité de code dynamique.
juste pour émettre l'opinion contraire, on peut faire l'hypothèse de toujours régler le MaxMetaspaceSize. Regrouper l'ensemble des applications du monde en 10 groupes (binaire-pensez-y) permet une discussion sur le pourquoi. Rappelez-vous cependant, le réglage de la limite ne contrôle que lorsque la collecte des ordures (CG) de cet espace se produira.
groupe 01: Applications avec toutes les Classes Non dynamiques
ce groupe vous place dans la bande stabilisée mentionnée ci-dessus. Dans ce cas, la taille à définir est assez facile à déterminer (tout comme MaxPermSize était) et il n'y aura pas beaucoup, s'il y en a, GC de toute façon.
groupe 10: Applications avec Classes dynamiques
étant donné la prolifération de bibliothèques tierces très puissantes, n'est-ce pas presque toutes les applications de ce groupe? Souvent, vous ne vous souciez pas si la Bibliothèque est Scala/Groovy/etc, il fait exactement ce que vous voulez donc il est utilisé. Quelle est la valeur de remplir Metaspace avec le la litière de morts (dynamique) des classes? Quand le GC arrivera, ça coûtera cher. Je préférerais limiter la taille, rendre le GC plus fréquent (mais moins de temps de pause pour chacun), et plus facilement exécuter plusieurs applications sur le même matériel sans avoir des préoccupations au sujet de leurs métaspaces individuels courant dans l'autre.
Réponse de @eckes commentaires:
je mettrais un maximum qui est assez grand pour ne pas déclencher normal situation. La raison pour laquelle je dis cela est, qu'un système pourrait agir très erratique et difficile à contrôler si la mémoire native est épuisée ou sauvage la permutation se passe. Mich pire qu'une OOM ou Java freeze. Exemple utiliser 2 Go (prévoir un système pour avoir 2 Go de tampons libres au minimum)