Compromis de vitesse des options Java-Xms et-Xmx

l'argument -Xmx définit la taille de mémoire maximale que le tas peut atteindre pour la JVM. Vous devez bien connaître votre programme et voir comment il fonctionne sous charge et régler ce paramètre en conséquence. Une valeur faible peut causer OutOfMemoryExceptions ou une très mauvaise performance si la mémoire tas de votre programme atteint la taille maximum. Si votre programme tourne dans 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 tas pour la JVM. Cela signifie que lorsque vous démarrez votre programme, la JVM alloue instantanément cette quantité de mémoire. Ceci est utile si votre programme consomme une grande quantité de mémoire tas dès le début. Cela permet d'éviter que la JVM n'augmente constamment le volume et d'y gagner en performance. Si vous ne savez pas si ce paramètre va vous aider, ne pas utiliser .

en résumé, il s'agit d'un compromis que vous devez décider basé uniquement sur le comportement de mémoire de votre programme.

j'ai constaté que dans certains cas, trop de mémoire peut ralentir le programme.

par exemple, j'avais un moteur transform basé sur l'hibernation qui a commencé à fonctionner lentement à mesure que la charge augmentait. Il s'est avéré que chaque fois que nous avons obtenu un objet de la db, hibernate vérifiait la mémoire pour les objets qui ne seraient jamais utilisés à nouveau.

La solution était d'expulser les anciens objets de la session.

Stuart

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, qui est en effet lent.
2. si votre programme tourne plus lentement ou plus vite dépend des références que la VM doit gérer et nettoyer. Le GC n'a pas besoin de parcourir la mémoire allouée pour trouver des objets abandonnés. Il sait que ce sont des objets et la quantité de mémoire qu'ils attribuent par la cartographie de référence. Donc balayer dépend de la taille des 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 VM, lorsque la VM essaie d'allouer la mémoire fournie par votre système D'exploitation et si vous utilisez le swap (qui conduit à nouveau à 1.)

il est difficile de dire comment l'allocation de mémoire affectera votre vitesse. Cela dépend de l'algorithme de collecte des ordures que la JVM utilise. Par exemple, si votre ramasseur d'ordures a besoin de faire une pause pour faire une collecte complète, puis si vous avez 10 mémoire de plus que vous avez vraiment besoin, alors le collecteur aura 10 ordures de plus à nettoyer.

si vous utilisez java 6, Vous pouvez utiliser le jconsole (dans le répertoire bin du jdk) pour attacher à votre processus et regarder comment le le collectionneur se comporte. En général, les collecteurs sont très intelligents et vous n'aurez pas besoin de faire n'importe quel réglage, mais si vous avez un besoin il y a de nombreuses options que vous avez l'utilisation pour affiner le processus de collecte.

> 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)