Est-il judicieux de définir la même taille de segment de mémoire JVM maximale et minimale?

La raison principale pour définir -Xms est pour si vous avez besoin d’un certain tas au démarrage. (Empêche les erreurs OutOfMemoryErrors de se produire au démarrage.) Comme mentionné ci-dessus, si vous avez besoin que le segment de démarrage corresponde au segment maximal, vous devez le faire correspondre. Sinon, vous n’en avez pas vraiment besoin. Demande simplement à l’application de prendre plus de mémoire dont elle pourrait avoir besoin. Regarder votre mémoire utiliser au fil du temps (profilage) tout en testant la charge et en utilisant votre application devrait vous donner une bonne idée de ce qu’il faut définir. Mais ce n’est pas la pire chose de les mettre au même au démarrage. Pour beaucoup de nos applications, je commence avec 128, 256 ou 512 min (démarrage) et un gigaoctet (maximum) (pour les applications autres que les serveurs d’applications).

Je viens de trouver cette question sur le dépassement de stack qui peut également être utile effet secondaire pour augmenter la taille maxpermsize et max . Ça vaut le coup d’oeil.

La réponse de Peter est correcte en ce -Xms que -Xms est alloué au démarrage et qu’il atteindra -Xmx (taille maximale du tas), mais il est un peu trompeur dans la formulation de sa réponse. ( Désolé Peter je sais que tu connais ce truc froid ).

Définir ms == mx désactive effectivement ce comportement. Bien que ce soit une bonne idée dans les anciennes JVM , ce n’est plus le cas. En augmentant et en réduisant le segment de mémoire, la machine virtuelle Java peut s’adapter à l’augmentation de la pression sur la mémoire tout en réduisant le temps de pause en réduisant le tas lorsque la pression de la mémoire est réduite. Parfois, ce comportement ne vous offre pas les avantages de performances escomptés et, dans ce cas, il est préférable de définir mx == ms . OOME est lancé lorsque le tas dépasse 98% du temps passé à collecter et que les collections ne peuvent pas récupérer plus de 2% de ce temps. Si vous n’êtes pas à la taille maximale, alors la JVM augmentera simplement pour que vous dépassiez ces limites. Vous ne pouvez pas avoir une OutOfMemoryError au démarrage, sauf si votre OutOfMemoryError de OutOfMemoryError atteint la taille maximale du segment et répond aux autres conditions définissant une OutOfMemoryError .

Pour les commentaires qui sont entrés depuis que j’ai posté. Je ne sais pas ce que montre le blog de JMonitor, mais cela vient du collecteur PSYoung .

 size_t desired_size = MAX2(MIN2(eden_plus_survivors, gen_size_limit()), min_gen_size()); 

Je pourrais faire plus de recherches, mais je parierais que je trouverais un code qui a le même objective dans les ParNew et PSOldGen et CMS Tenured . En fait, il est peu probable que le CMS puisse retourner de la mémoire à moins qu’il y ait eu un Concurrent Mode Failure . Dans le cas d’un CMF le collecteur en série s’exécutera et cela devrait inclure un compactage après lequel le sumt du tas serait probablement propre et donc susceptible d’être désalloué.

Si je comprends bien, définir la même taille pour les deux supprime l’étape supplémentaire de redimensionnement de segment de mémoire qui pourrait être en votre faveur si vous savez à peu près combien de segment de mémoire vous allez utiliser. En outre, une taille de segment de mémoire importante réduit les invocations GC au point où cela se produit très rarement. Dans mon projet actuel (parsing de risque des trades), nos moteurs de risque ont à la fois Xmx et Xms à la même valeur, ce qui est assez élevé (environ 8Gib). Cela garantit que même après une journée entière d’invocation des moteurs, presque aucun GC n’a lieu.

En outre, j’ai trouvé une discussion intéressante ici .

Certainement yes pour une application serveur. Quel est l’intérêt d’avoir autant de mémoire sans l’utiliser? (Non, cela ne permet pas d’économiser de l’élecsortingcité si vous n’utilisez pas de cellule mémoire)

JVM aime la mémoire. Pour une application donnée, plus la JVM possède de mémoire, moins elle effectue de GC. La meilleure partie est que plus d’objects mourront jeunes et moins d’occupation.

Surtout au démarrage du serveur, la charge est même supérieure à la normale. Il est mort cérébral de donner au serveur une petite mémoire avec laquelle travailler à ce stade.

D’après ce que je vois ici à l’ adresse http://java-monitor.com/forum/showthread.php?t=427, la machine virtuelle testée commence par le paramètre Xms, mais libère la mémoire dont elle n’a pas besoin et qui la prendra jusqu’à la marque Xmx quand elle en a besoin.

Sauf si vous avez besoin au départ d’une partie de la mémoire dédiée à un gros consommateur de mémoire, il n’ya pas grand chose à mettre dans un Xms élevé = Xmx. On dirait que la désallocation et l’allocation se produisent même avec Xms = Xmx