Y a-t-il un avantage à définir Xms et Xmx sur la même valeur?
Habituellement, je mets -Xms512m et -Xmx1g de sorte que lorsque la JVM démarre, elle alloue 512 Mo et augmente progressivement le tas à 1 Go si nécessaire. Mais je vois ces valeurs définies sur same say 1g dans une instance de serveur dédié. Y a-t-il un avantage à avoir les deux mis à la même valeur?
5 answers
Eh bien, il y a deux ou trois choses.
- Le programme commencera par la valeur-Xms et si la valeur est inférieure, il forcera finalement GC à se produire plus fréquemment
- Une fois que le programme atteint le tas-Xms, la jvm demande au système d'exploitation de la mémoire supplémentaire et finit par saisir-Xmx qui nécessite du temps supplémentaire conduisant à un problème de performance, vous pouvez aussi bien le définir à cela au début en évitant la jvm pour demander de la mémoire supplémentaire.
Il est très bien répondu ici - https://developer.jboss.org/thread/149559?_sscc=t
De la documentation Oracle Java SE 8:
Https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/sizing.html Par défaut, la machine virtuelle agrandit ou rétrécit le tas à chaque collection pour essayer de garder la proportion d'espace libre aux objets vivants à chaque collection dans une plage spécifique. Cette plage cible est définie en pourcentage par les paramètres
-XX:MinHeapFreeRatio=<minimum>et-XX:MaxHeapFreeRatio=<maximum>, et la taille totale est limitée en dessous par -Xms<min>et au-dessus par-Xmx<max>. Réglage-Xmset {[5] } à la même valeur augmente la prévisibilité en supprimant le dimensionnement le plus important décision de la machine virtuelle. Cependant, la machine virtuelle est ensuite, impossible de compenser si vous faites un mauvais choix.
Si la valeur de-Xms et-Xmx est la même, la JVM n'aura pas à ajuster la taille du tas, ce qui signifie moins de travail pour la JVM et plus de temps pour votre application. mais si la valeur choisie est un mauvais choix pour-Xms, une partie de la mémoire allouée ne sera jamais utilisée car le tas ne rétrécira jamais et si c'est un mauvais choix pour-Xmx, vous obtiendrez OutOfMemoryError.
Il y a quelques avantages.
- si vous savez que la taille va augmenter au maximum, par exemple dans un benchmark, vous pouvez aussi bien commencer par la taille dont vous savez que vous avez besoin.
- vous pouvez obtenir de meilleures performances en donnant au programme plus de mémoire qu'il pourrait naturellement se donner. YMWV
En général, je ferais du Xms une valeur que je suis confiant qu'il utilisera, et le double ceci pour la marge de manœuvre pour les futurs cas d'utilisation ou situations pour lesquels nous n'avons pas testé. c'est à dire une taille, nous n' attendez, mais il pourrait utiliser.
En bref, le maximum est le point que vous préférez que le programme échoue plutôt que d'utiliser plus.
AFAIK Une raison de plus, est que l'expansion du tas est un événement stop-the-world; définir ceux-ci à la même valeur empêchera cela.
- L'application subira des GC fréquents avec une valeur-Xms inférieure.
- Chaque fois que vous demandez plus de mémoire du système d'exploitation avec du temps de consommation.
- Par-dessus tout, si votre application est critique en termes de performances, vous voudrez certainement éviter l'échange de pages mémoire vers/depuis le disque, car cela entraînera une consommation de GC plus longue. Pour éviter cela, la mémoire peut être verrouillé. Mais si Xms et Xmx ne sont pas identiques, la mémoire allouée après l'allocation initiale ne sera pas verrouillée.