Est-il bon de mettre le max et le min de la JVM de la taille du segment de la même manière?

Actuellement dans notre environnement de test le max et le min de la JVM de la taille du segment sont réglés à la même valeur, fondamentalement, autant que le serveur dédié machine le permet pour notre application. Est-ce la meilleure configuration pour plus de performance ou serait de donner la JVM d'une gamme de mieux?

Lorsque vous définissez le maximum, il alloue la quantité de mémoire virtuelle sur démarrer. Cependant, la quantité de mémoire utilisée augmente lentement que le segment de mémoire est utilisé. Même lorsque vous spécifiez une taille minimale, il n'utilisez pas cet espace immédiatement au lieu de cela, il permet à des tas de grandir à cette taille rapidement.

InformationsquelleAutor Clay3981 | 2011-07-28

java jvm

9

Raison principale pour définir le -Xms est pour si vous avez besoin d'un certain segment de mémoire au démarrage. (Empêche OutOfMemoryErrors de passe au démarrage.) Comme mentionné ci-dessus, si vous avez besoin du démarrage tas de match le tas max, c'est quand vous match. Sinon, vous n'avez pas vraiment besoin. Juste demande à l'application de prendre plus de mémoire qu'il peut, en fin de compte. En regardant votre utilisation de la mémoire au fil du temps (profilage), tandis que les tests de charge et l'utilisation de votre application devrait vous donner une bonne idée de ce qui à besoin de les mettre à. Mais ce n'est pas la pire chose pour les mettre à la même au démarrage. Pour beaucoup de nos applications, j'ai réellement commencer avec quelque chose comme de 128, 256 ou 512 pour min (démarrage) et un gigaoctet pour max (c'est pour la non application de serveur d'applications).

Viens de trouver cette question sur un débordement de pile qui peut être utile effets secondaires-pour-augmenter-maxpermsize-et-max-heap-taille. Vaut le coup d'oeil.
- Pouvez-vous vraiment éviter OOMEs sans réglage max taille de segment de mémoire? Je pensais que le tas pourrait croître jusqu'à la taille maximale avant un OOME, même au démarrage. J'ai toujours pensé que c'était pour éviter de GC des cycles et des tas redimensionne si vous saviez que le programme serait d'une quantité minimale de mémoire, de toute façon.
- Tout ce que je peux dire, c'est que j'ai eu OOME de se produire si le min taille de segment de mémoire est trop faible. Jusqu'à la fin avec trop d'objets sur le tas trop vite et pas assez de temps pour réallouer la mémoire et obtenir un plus gros tas, ni de déchets à collecter des objets. Donc, la raison principale de la mise Min tas est de s'assurer que vous avez le droit d'espace pour grandir dans la JVM/démarrage de l'application. Après cela, vous nous l'espérons vous avoir contrôlé la croissance qui vous permet d'atteindre le max de la taille du segment et/ou GC.
- Vous dites "avec pas assez de temps pour réallouer la mémoire et obtenir un plus gros tas, ou garbage collect". Le problème, c'est le GC peut être une opération de blocage. Le temps nécessaire doit être hors de propos. La seule chose à laquelle je pense est le cas où il n'y a pas assez de mémoire disponible pour le système d'exploitation pour donner à votre processus. Dans ce cas, en commençant avec un petit Xms serait d'initialiser et de jeter un OOME alors que de commencer avec un gros Xms serait simplement de ne pas initialiser la machine virtuelle, ce qui n'est guère mieux.
- Probablement. J'ai tendance à parler de mon expérience. J'apprends beaucoup de choses que je vais le long. Donc, tout ce que je peux apprendre à augmenter mes connaissances est génial. (une partie de elle est d'être dans un petit magasin: jack de tous les métiers, maître de rien).
InformationsquelleAutor Chris Aldrich
27

Peter 's réponse est correcte dans ce -Xms est alloué au démarrage et il va grandir pour -Xmx (max taille de segment de mémoire) mais c'est un peu trompeur dans la façon dont il a formulé sa réponse. (Désolé Pierre, je sais que vous savez ce truc froid).

Réglage ms == mx efficacement désactive ce comportement. Bien que cette habitude d'être une bonne idée dans les anciennes machines virtuelles, il n'est plus le cas. Agrandissement et réduction du segment de mémoire permet à la machine de s'adapter à des augmentations de la pression sur la mémoire encore réduire le temps de pause en réduisant le segment de mémoire lorsque la mémoire de la pression est réduite. Parfois, ce comportement ne vous donne pas les avantages de performance que vous attendez et dans ces cas, il est préférable de mettre en mx == ms.
OOME est levée lorsque le segment est plus que 98% de temps est consacré à la collecte et les collections ne peut pas récupérer plus de 2% de que. Si vous n'êtes pas au max des tas de la taille puis la JVM va tout simplement grandir, de sorte que vous sommes au-delà des frontières. Vous ne pouvez pas avoir un OutOfMemoryError au démarrage, à moins que votre tas de hits le max de la taille du segment et répond aux autres conditions qui définissent une OutOfMemoryError.

Pour les commentaires qui nous sont parvenus depuis que j'ai posté. Je ne sais pas ce que le JMonitor blog entrée est visible mais c'est à partir de la PSYoung collector.
```
size_t desired_size = MAX2(MIN2(eden_plus_survivors, gen_size_limit()),
                           min_gen_size());
```
Je pouvais faire plus de creuser, mais je serais prêt à parier que j'avais trouver le code qui sert le même but dans le ParNew et PSOldGen et CMS Tenured implémentations. En fait, il est peu probable que la CMS serait en mesure de revenir mémoire, sauf si il y a eu un Concurrent Mode Failure. Dans le cas d'un CMF la série collector, et qui devrait inclure un compactage après, le haut de tas plus de chance d'être propre et donc éligibles pour être libéré.

InformationsquelleAutor Kirk
4

Autant que je sache, définissant à la fois de la même taille l'étape supplémentaire de tas de redimensionnement qui pourrait être en votre faveur si vous avez assez bien savoir combien de tas que vous allez utiliser. Aussi, ayant une grande taille de segment de mémoire réduit GC invocations au point qu'il se passe très peu de temps. Dans mon projet actuel (analyse des risques des métiers), notre risque de moteurs à la fois Xmx et Xms à la même valeur assez grande (environ 8Gib). Cela garantit que même après une journée entière d'invoquer les moteurs, presque pas de GC.

Aussi, j'ai trouvé une discussion intéressante ici.
- Tas le redimensionnement n'est pas la même chose que GC invocations. Chaque fois que vous créez un objet, il doit (éventuellement) être collectées. Donc, à moins que votre application ne jamais instancie un nouvel objet après que vous avez atteint votre maximum de la taille du segment, vous aurez certainement avoir de périodique collecte des poubelles.
- Oui, je le sais et c'est pourquoi je mentionne séparément.
InformationsquelleAutor Sanjay T. Sharma
2

Certainement yes pour un serveur d'application. Quel est l'intérêt d'avoir autant de mémoire mais ne l'utilise pas?
(Non, ce n'est pas pour économiser de l'électricité si vous n'utilisez pas une cellule de mémoire)

JVM aime mémoire. Pour une application donnée, plus la mémoire de la JVM a, moins GC qu'il effectue. La meilleure partie est plus les objets meurent jeunes et moins foncière.

Surtout lors d'un démarrage du serveur, la charge est encore plus élevé que la normale. Il est en état de mort cérébrale à donner server un petit mémoire de travail à ce stade.
- Combien GC est effectué n'a rien à voir avec la façon dont beaucoup de la taille du segment y est, il a à voir avec combien d'objets sont créés et libéré. Plus grande taille de segment de mémoire causera moins fréquentes, mais plus gros et plus dérangeant que de la collecte des ordures s'en utilisant le traditionnel oracle de collecte des ordures algorithme. Alors le plus gros n'est pas mieux. Le comportement exact dépendra de la JVM. En outre, comme mentionné dans les autres réponses, Xms n'est pas une limitation sur la quantité de la JVM a, lors de leur lancement. En aparté, la langue comme "mort cérébrale" n'est pas utile.
- À l'appui de cette réponse n'est cet article à propos de la mise au point du Serveur Weblogic, qui ne disent, "Oracle recommande de mettre le minimum de la taille du segment (-Xms) égale à la taille maximale du tas (-Xmx) afin de minimiser la collecte des poubelles."
InformationsquelleAutor irreputable
1

De ce que je vois ici, à http://java-monitor.com/forum/showthread.php?t=427
la JVM en cours de test commence avec la Xms, mais la VOLONTÉ de libérer la mémoire qu'il n'a pas besoin et il va le prendre jusqu'à la Xmx marque quand il en a besoin.

Sauf si vous avez besoin d'un morceau de la mémoire dédiée pour une grande mémoire du consommateur d'abord, il n'y a pas beaucoup d'un point à mettre dans une haute Xms=Xmx. Ressemble de libération de la mémoire et de l'allocation se produire même avec Xms=Xmx
- Le test est à l'aide d'un client de la machine virtuelle java JVM de serveur ne désalloue la mémoire une fois acquis.
InformationsquelleAutor Shock

Vous devez vous connecter pour publier un commentaire.