Compromis rapide entre les options -Xms et -Xmx de Java

Question

Étant donné ces deux commandes

A:

$ java -Xms10G -Xmx10G myjavacode input.txt

B:

$ java -Xms5G -Xmx5G myjavacode input.txt

J'ai deux questions:

1. Étant donné que la commande A réserve plus de mémoire avec ses paramètres, A sera-t-il plus rapide que B?
2. Comment -Xmx et -Xms affectent-ils le processus en cours et la sortie de mon programme?

Answer 1

Cela dépend du CP utilisé par votre java. Les GC parallèles pourraient mieux fonctionner avec des paramètres de mémoire plus importants - je ne suis toutefois pas un expert sur ce point.

En général, si vous avez une mémoire plus grande, moins elle doit être utilisée fréquemment, plus le niveau de mémoire utilisé est élevé - il y a beaucoup de place pour les déchets. Cependant, lorsqu'il s'agit d'un CPG, celui-ci doit utiliser davantage de mémoire, ce qui peut être plus lent.

Answer 2

L'argument -Xmx définit la taille maximale de mémoire que le segment de mémoire peut atteindre pour la machine virtuelle Java. Vous devez bien connaître votre programme, voir comment il se comporte sous charge et définir ce paramètre en conséquence. Une valeur faible peut entraîner des OutOfMemoryExceptions ou des performances très médiocres si la mémoire de tas de votre programme atteint la taille de tas maximale. Si votre programme est exécuté sur un serveur dédié, vous pouvez définir ce paramètre plus haut car il n’affectera pas les autres programmes.

L'argument -Xms définit la taille initiale de la mémoire de tas pour la machine virtuelle Java. Cela signifie que lorsque vous démarrez votre programme, la machine virtuelle allouera cette quantité de mémoire instantanément. Ceci est utile si votre programme consomme une grande quantité de mémoire de tas dès le début. Cela évite à la JVM d’augmenter constamment le tas et d’y gagner en performance. Si vous ne savez pas si ce paramètre vous aidera, ne l'utilisez pas .

En résumé, il s'agit d'un compromis que vous devez décider uniquement en fonction du comportement de la mémoire de votre programme.

Answer 3

J'ai constaté que, dans certains cas, une mémoire excessive peut ralentir le programme.

Par exemple, un moteur de transformation basé sur l'hibernation a démarré lentement à mesure que la charge augmentait. Il s’est avéré que chaque fois que nous obtenions un objet de la base de données, hibernate vérifiait dans la mémoire les objets qui ne seraient plus jamais utilisés.

La solution consistait à expulser les anciens objets de la session.

Stuart

Answer 4

1. L'allocation dépend toujours de votre système d'exploitation. Si vous allouez trop de mémoire, vous pourriez avoir des portions chargées dans le swap, ce qui est effectivement lent.
2. Que votre programme s'exécute plus lentement ou plus rapidement dépend des références que la VM doit gérer et nettoyer. Le CPG n'a pas à parcourir la mémoire allouée pour rechercher des objets abandonnés. Il sait que ce sont des objets et la quantité de mémoire allouée par mappage de référence. Le balayage dépend donc de la taille de vos objets. Si votre programme se comporte de la même manière dans les deux cas, le seul impact sur les performances devrait être le démarrage de la machine virtuelle, lorsque cette dernière tente d'allouer de la mémoire fournie par votre système d'exploitation et que vous utilisez le swap (qui conduit à nouveau à 1.)

Answer 5

Il est difficile de dire comment l’allocation de mémoire affectera votre vitesse. Cela dépend de l'algorithme de récupération de place utilisé par la machine virtuelle Java. Par exemple, si votre ramasse-miettes a besoin de faire une pause pour effectuer une collecte complète, si vous avez 10 fois plus de mémoire que nécessaire, le collecteur aura 10 poubelles de plus à nettoyer.

Si vous utilisez java 6, vous pouvez utiliser la commande jconsole (située dans le répertoire bin du jdk) pour attacher à votre processus et observer le comportement du collecteur. En général, les collecteurs sont très intelligents et vous n’aurez pas besoin de réglage, mais si vous en avez besoin, vous disposez de nombreuses options pour affiner le processus de collecte.

Answer 6

> C:\java -X

-Xmixed           mixed mode execution (default)
-Xint             interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
                  set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
                  append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
                  prepend in front of bootstrap class path
-Xnoclassgc       disable class garbage collection
-Xincgc           enable incremental garbage collection
-Xloggc:<file>    log GC status to a file with time stamps
-Xbatch           disable background compilation
-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size
-Xprof            output cpu profiling data
-Xfuture          enable strictest checks, anticipating future default
-Xrs              reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni       perform additional checks for JNI functions
-Xshare:off       do not attempt to use shared class data
-Xshare:auto      use shared class data if possible (default)
-Xshare:on        require using shared class data, otherwise fail.

Les options -X ne sont pas standard et peuvent être modifiées sans préavis.

(copier / coller)

Answer 7

C’est toujours la question que j’avais quand je travaillais sur une de mes applications qui créait un nombre énorme de threads par requête.

C’est donc une très bonne question et elle comporte deux aspects:
1. Si mes valeurs Xms et Xmx doivent être identiques.
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; - La plupart des sites Web et même de la documentation d'Oracle suggèrent qu'il en soit de même. Toutefois, il est conseillé de laisser 10 à 20% de mémoire tampon entre ces valeurs afin de donner à votre application une option de redimensionnement de tas, en cas de forte augmentation soudaine du trafic OU de fuite mémoire accidentelle.

2. Dois-je commencer mon application avec une taille de segment inférieure?
& nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; - Alors, voici la chose - peu importe ce que GC Algo utilise (même G1), un gros tas a toujours un certain compromis. L’objectif est d’identifier le comportement de votre application en fonction de la taille du segment de mémoire que vous pouvez autoriser à mettre en pause en raison de la latence et du débit.
   & nbsp; & nbsd; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; pas en tas) mais n'occupe pas l'espace objet lourd, alors je suggère d'avoir une valeur inférieure de Xms.
   & nbsp; & nbsf; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; & nbsp; peut définir pour tolérer ces pauses STW. Cela signifie qu’il faut identifier le temps de réponse maximum de vos demandes entrantes que vous pouvez tolérer et accorder la taille de tas minimale.