comment choisir la taille du tas jvm?
Ce que je fais habituellement concernant la taille du tas jvm est de définir la valeur maximale très élevée pour éviter L'infâme OutOfMemoryException.
Cependant, cette stratégie (ou manque de stratégie) ne semble pas être vraiment intelligente. :-).
Ma question Est de savoir comment choisir les valeurs min et max, et la différence entre les deux (max-min devrait-il être petit ou grand?). Par exemple, à partir de ici:
Si le tas initial est trop petit, le Le démarrage de l'application Java devient lent comme la JVM est forcée d'effectuer collecte des ordures fréquemment jusqu'à le tas a grandi à un plus de taille raisonnable. Pour optimiser le démarrage performance vous devez définir l'initiale taille de tas au même que le maximum la taille du segment.
Merci.
6 réponses
Ma question est de savoir comment choisir le min et les valeurs maximales, et la différence entre les deux (devrait max-min être petit ou grand?)
Réponse courte: ne devinez pas, profilez votre application.
Jconsole peut vous donner des données de haut niveau utiles telles qu'un sentiment pour l'ensemble résident principal par rapport aux données transitoires que nous allouons normalement et que nous collectons. Ce que vous verrez si vous regardez l'onglet mémoire de cet affichage est généralement quelque chose comme un en dents de scie. Le coin inférieur des dents de scie est à peu près là où je définirais normalement le minimum de tas alors que j'utiliserais le pic ou la pente des dents de scie pour expérimenter avec un maximum de tas. Si vos dents sont très raides, vous pourriez envisager un gros tas juste pour retarder la collecte des ordures. Cependant, si ce n'est pas le cas, vous pouvez essayer un maximum de tas plus petit pour voir si cela pourrait laisser plus de ressources pour d'autres processus sur votre machine (par exemple).
Vous devriez également considérer le serveur VM car cela provoquera un comportement de récupération de place différent.
Tout cela dit, vous devez également utiliser un outil plus détaillé tel que jvisualvm pour profiler l'utilisation de la mémoire de votre processus . Il est possible que vous ayez une fuite de mémoire ou un allocateur gourmand que vous pourriez régler ou éliminer. Cela changerait complètement vos besoins de tas.
Vous devez activer la journalisation GC et vérifier l'emplacement de votre Moo.
-verbose:gc
-Xloggc:gc.log
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
Vous pouvez rencontrer des limites d'espace perm, ajuster via -XX:MaxPermSize=YYYm
Quoi qu'il en soit pour répondre à votre question, je commence sans minimum et fixe le maximum relativement élevé. Je dessine ensuite le journal gc et découvre où se trouve mon état de place; choisissez visuellement une taille supérieure à la moyenne pour les différentes générations. Le lire comme un tableau financier, vous aurez envie de voir une bonne propagation dans les nouvelles générations et cohérente croissance et collecte dans la génération tenured. Comme mentionné également Graphique votre espace perm pour vous assurer que vous n'êtes pas en constante augmentation.
GC tuning est un art, en aucun cas une science.
En effet, définir aveuglément une énorme valeur max n'est pas vraiment une bonne idée (mesurer, ne pas deviner) et cette stratégie conduira à de très longs GCs majeurs" stop the world "qui pourraient ne pas être souhaitables du point de vue de l'expérience utilisateur (toujours garder à l'esprit que "plus le tas est grand, plus le GC majeur").
Cela dit, il n'y a pas de réponse générique à votre question, chaque application a des besoins différents. En fait, je suggère de profiler votre application et de régler le tas pour trouver un bon compromis entre la fréquence (majeure) GC et la durée (majeure) GC tout en minimisant le temps de réponse à l'utilisateur final. Je suggère chaleureusement de lire ce grand blog post (et tous les autres) de Kirk Pepperdine pour plus de détails.
Juste pour répondre à la partie Valeur min et max, j'utilise toujours les mêmes valeurs (pour de meilleures performances de démarrage et une meilleure reproductibilité).
La bonne réponse est: Il n'y a pas de bonne réponse chaque projet est différent et vous devrez affiner votre configuration de taille de tas sur une base par projet. Je commencerais petit et augmenterais progressivement la taille du tas jusqu'à ce que votre application fonctionne comme prévu.
Vous avez raison, définir une valeur max énorme n'est pas une bonne idée.
Si vous rencontrez un OOME, je commencerais en fait par augmenter la mémoire maximale autant que possible, et voir si cela résout le problème. Laissez votre machine absorber le problème de performance, d'abord. Si le problème persiste, vous pouvez rechercher les diagnostics de performance pour identifier les goulots d'étranglement et travailler sur les zones où votre application risque de fuir ou de monopoliser le plus de mémoire.
Jeff Atwood a un bel article sur CodingHorror qui explique cette attitude; le plus la solution rentable à un problème de performance consiste à lancer du matériel (ou dans ce cas, des ressources de mémoire accrues) sur le problème, avant d'investir du temps de développement dans le dépannage:
C'est une très mauvaise idée d ' "ignorer le paramètre-Xms" car il y a généralement d'autres applications et processus s'exécutant sur la même boîte. Vous voulez que votre application démarre avec la quantité maximale de RAM allouée, donc si elle échoue, elle échoue pendant que vous regardez les journaux de démarrage, et non à 4h00 quand une autre application a pris de la RAM supplémentaire sur la boîte, et votre JVM ne peut pas croître en taille.
En bref, toujours définir JVM min et mélanger la taille avec la même valeur.