comment choisir la taille du tas jvm?

Question

Ce que je fais d'habitude concernant la taille du tas jvm est de mettre la valeur max vraiment haute pour éviter l'infâme OutOfMemoryException. Cependant, cette stratégie (ou manque de stratégie) ne semble pas très 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 here:

si le tas initial est trop petit, le Java démarrage de l'application devient lente que la machine virtuelle Java est forcé d'effectuer la collecte des ordures fréquemment jusqu'à ce que le tas a augmenté à un plus taille raisonnable. Pour une performance de démarrage optimale, vous devez définir la taille initiale du tas au même niveau que la taille maximale du tas .

merci.

Answer 1

Ma question est de savoir comment choisir le min et les valeurs max, et la différence entre les deux (devrait max-min être petite ou grande?)

Réponse courte: don Ne devinez pas, profilez votre application.

jconsole can give you useful high-level data comme un sentiment pour l'ensemble résident principal par rapport aux données transitoires que nous allouons normalement et la collecte des ordures. Ce que vous verrez si vous regardez l'onglet mémoire de cet écran est généralement quelque chose comme une dent de scie. Le coin inférieur des dents de scie est à peu près là où je placerais normalement le tas minimum 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, s'ils ne le sont pas, vous pouvez essayer un plus petit tas maximum pour voir si cela peut laisser plus de ressources pour d'autres processus sur votre machine (par exemple).

Vous devriez également considérer le server VM car cela entraînera un comportement différent de la récupération de place.

Tout cela dit, vous devriez également utiliser un outil plus détaillé tel que jvisualvm to profile the memory usage of your process. Il est possible que vous ayez une fuite de mémoire ou un allocateur glouton que vous pouvez régler ou éliminer. Cela changerait complètement vos besoins en tas.

Answer 2

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 voudrais commencer petit et augmenter progressivement la taille du tas jusqu'à ce que votre application fonctionne comme prévu.

Vous avez raison, définir une valeur maximale énorme n'est pas une bonne idée.

Answer 3

Vous devez activer la journalisation GC et vérifier l'affichage de votre MOO.

-verbose:gc 
-Xloggc:gc.log 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 

Vous pouvez rencontrer des limites de l'espace de perm, régler via -XX:MaxPermSize=YYYm

Quoi qu'il en soit pour répondre à votre question, je commence sans minimum et le maximum fixé relativement élevé. Je puis graver le log de gc et découvrir où mon état de stead est; choisir visuellement une taille supérieure à la moyenne pour les différentes générations. Lisez-le comme un tableau financier, vous voulez voir une bonne propagation dans les nouvelles générations et une croissance constante et la collecte dans la génération de longue date. Comme mentionné, tracez un graphique de votre espace perm pour vous assurer que vous n'augmentez pas constamment.

L'accordage GC est un art, en aucun cas une science.

Answer 4

Si vous rencontrez un OOME, je commencerais par augmenter la mémoire max autant que vous le pouvez, 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 consulter les diagnostics de performances pour identifier les goulets d'étranglement et travailler sur les zones où votre application risque de fuir ou de perdre le plus de mémoire possible.

Jeff Atwood a un bel article sur CodingHorror qui explique cette attitude; la solution la plus rentable à un problème de performance est de jeter le matériel (ou dans ce cas, les ressources de mémoire accrue) au problème, avant que le temps de développement d'investir dans le dépannage:

http://www.codinghorror.com/blog/archives/001198.html

Answer 5

En effet, la fixation d'un grand max la valeur à l'aveuglette n'est pas vraiment une bonne idée (mesurer, ne pas deviner) et cette stratégie conduira à de très longues GC "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 gros, plus le GC principal est important ").

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 vous suggère de profil votre application et régler le tas de trouver un bon compromis entre (majeur) fréquence de GC et (majeure) GC durée tout en réduisant le temps de réponse à l'utilisateur final. Je suggère chaudement de lire ce grand blog post (et tous les autres) de Kirk Pepperdine pour plus de détails. Pour répondre à la partie valeur min et max, j'utilise toujours les mêmes valeurs (pour de meilleures performances au démarrage et une meilleure reproductibilité).

Answer 6

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 à 04h00 quand une autre application a pris de la RAM supplémentaire sur la boîte, et votre JVM ne peut pas grossir. En bref, définissez TOUJOURS la taille minimale et la taille de mixage JVM avec la même valeur.