mercredi 14 avril 2010
02:50 | 
Publié par
Jean FRANCOIS |
Cet article propose de dégager de façon globale des règles de paramétrage de JVM GC. Elles constituent un point d’entré pour obtenir une plate-forme stable, mais pas un tuning fin. Pour cela, il faudra composer avec les spécificités de chaque application et de leurs consommations mémoire, ainsi que les optimisations offertes sur chaque JVM fonction de l’éditeur.
La JVM est un composant mangeure dans l’architecture Weblogic car c’est elle qui permet d’accéder à la ressource machine via l’O.S ou une infrastructure de virtualisation. Si ce composant fonctionne mal, c’est la totalité de la plate-forme WLS qui est impactée.
Les mécanismes de libération mémoire (ramasse-miette ou garbage collecte) permettent de libérer la mémoire des objets non utilisés à la place du développeur. Ces mécanismes se déclenchés sur des seuils d’occupation mémoire gérée par la JVM et peuvent impacter les temps de réponse des utilisateurs (bloquant) et consommer de la CPU.
REPARTITION MEMOIRE
ü Une partie pour les objets nouvellement crée (nursery ou young generation)
ü Une partie pour les objets plus anciens (tenured ou old generation)
(la nursery possédant deux sous zone selon le type de JVM appelées survivor ration)
GC : PRINCIPES D’EXECUTION
En concurrence | Le GC s’exécute en mode non bloquant pour l’application en parallèle des traitements utilisateur de la JVM. Ce mode et donc peux couteux pour les temps et la CPU mais peu efficace pour la libération mémoire |
En parallèle | Le GC s’exécute en mode stop the world. Les traitements utilisateur de la JVM sont bloqués durant le GC. Le GC s’exécute sur plusieurs Threads dédiés pour diminuer le temps d’interruption. Ce mode interrompt les traitements, mais et plus efficace pour la libération mémoire |
GC : YOUNG COLLECTOR
Ce type de GC est très peu couteux en temps, car il ne fait que déplacer des objets d’une zone à l’autre (de la nursery au survivor puis sur la tenured) et n’intervient que sur une partie de la Heap.
(Il est souvent préférable d’augmenter la valeur par défaut de la taille de la nursery pour éviter l’éviction d’objet de courte durée de vie dans la old generation intempestivement)
GC : OLD COLLECTOR
Ce type de GC est beaucoup plus couteux, car il parcourt toute la mémoire et utilise plusieurs algorithmes. Trois phases s’appliquent à ce GC :
Mark | Parcours de l’arbre des objets à partie de la racine et marque toutes les feuilles (objets utilisés) |
Sweep | Parcours de tous les objets indépendamment de l’arbre et libère tous les objets non marqués (libération des objets non utilisés) |
Compaction | Mouvement et regroupement des blocs mémoires utilisés pour avec plus d’espace libre contigu pour la mémoire libre (comme pour la défragmentation d’un disque) |
Ces deux phases peuvent s’exécuter en concurrence ou en parallèle (selon la stratégie choisie). Pour la partie compaction, on peut jouer sur la taille à défragmenter (full ou partiel) par GC. Si la compaction n’est pas efficace, on risque d’avoir des zones libres non utilisables car trop petites (Dark Matter)
GC : AUTO OPTIMISATION
Mémoire | Avec ou sans nursery de taille variable |
Mark | Parallèle ou Concurrent |
Sweep | Parallèle ou Concurrent |
Compaction | Partiel ou Total |
GC : INTEMPESTIF
Deux types recensés :
ü Les GC déclenchés par le code JAVA avec la méthode System.gc()
ü Les GC déclenchés par un client RMI
One of the most commonly encountered uses of explicit GC occurs with RMI's distributed garbage collection (DGC). Applications using RMI refer to objects in other JVMs. Garbage can't be collected in these distributed applications without occasional local collection, so RMI forces periodic full collection. The frequency of these collections can be controlled with properties. For example,
java -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 ...
specifies explicit collection once per hour instead of the default rate of once per minute. However, this may also cause some objects to take much longer to be reclaimed. These properties can be set as high as Long.MAX_VALUE to make the time between explicit collections effectively infinite, if there is no desire for an upper bound on the timeliness of DGC activity.
GC : ANALYSE
Pour analyser le comportement de la JVM sur ses GC, vous pouvez active un log spécifique qui restitue toutes les actions de cette nature. Pour mettre en place et exploiter les logs GC, reporter vous au site suivant : LOG GC
Paramètre GC (avec 2 threads ou plus pour les Parallèles)
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=2 -XX:+CMSParallelRemarkEnabled
Eviter les GC parasite
-XX:+DisableExplicitGC -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
optthruput | (Defaut) pour minimiser le temps global d’exécution (batch, …). |
optavgpause | pour minimiser la durée de chaque pause. |
gencon | destiné aux applications web. L’algorithme Générationnel Concurrent communément utilisé dans les JVM Sun est optimisé pour les objets à courte durée de vie. |
subpools | pour les serveurs à grand nombre de processeurs (>16). |
A la différence de l’implémentation GenCon de Sun qui comprend trois zones (Young, Tenurd et Permanent), celle d’IBM n’en comporte que deux (Young et Old).
Stratégie
-XgcPrio:[ throughput/pausetime/deterministic]
Exemple
-XpauseTarget=10 -Xgcprio:pausetime
Fixer une politique
-XXsetGC:[gen/single][par/con][par/con]
Memory mark sweep
Exemple
-XXsetGC:genconcon
(Le paramétrage –XxsetGC:genconcon donnant souvent de bons résultats en retaillant la nursery)
Single spaced | Generational | |
Stop-the-world (throughput) | -Xgc:singlepar (-Xgc:parallel, -XXsetgc:singleparpar) | -Xgc:genpar (-XXsetgc:genparpar) |
Mostly concurrent (pause times) | -Xgc:singlecon (-XXsetgc:singleconcon) | -Xgc:gencon (-XXsetgc:genconcon) |
Single spaced | Generational | |
Stop-the-world (throughput) | When the heap is full, all Java threads are stopped and every CPU is used to perform a complete garbage collection of the entire heap. A parallel collector can have longer pause times than concurrent collectors, but it maximizes throughput. Even on single CPU machines, this maximized performance makes parallel the recommended garbage collector, provided that your application can tolerate the longer pause times | -Xgc:genpar (-XXsetgc:genparpar) |
Mostly concurrent (pause times) | What is unique about the concurrent garbage collectors is that they remove garbage collection pauses completely. Using these garbage collectors, the heaps can be gigabyte-size and there will be no long pauses. However, keep in mind that concurrent garbage collectors trade memory throughput for reduced pause time. It takes longer between the time the object is referenced the last time and the system detects and reclaims it; in other words it takes longer for the object to die. The natural consequence of this is that you will most likely need a larger heap with a concurrent garbage collector than you need with any other. In addition, if your ordinary Java threads create more garbage than the concurrent garbage collector manages to collect, there will be pauses while the Java threads are waiting for the concurrent garbage collector to complete its cycle. | In this garbage collector, objects are allocated in the young generation. When the young generation (called a nursery) is full,.stops-the-world. and moves the objects that are still live in the young generation to the old generation. An old collector thread runs in the background all the time; it marks objects in the old space as live and removes the dead objects, returning them to the JVM as free space. The advantage of the generational concurrent garbage collector compared to the single spaced concurrent garbage collector is that it has a higher memory throughput. |
La stratégie déterministe est spécifique à JRockit et propose d’utiliser la JVM dans des applications temps réel. Ces types de GC combinent l’ensemble des stratégies avec des fenêtres glissantes afin de garantir un temps de réponse prédictible (JVM de grande capacité avec de la CPU dédié aux GC).
Libellés :
Inscription à :
Publier les commentaires (Atom)
AUTEUR
- Jean FRANCOIS
- Carrières Sur Sein, Yvelines, France
- Consultant Oracle (Ancien consultant BEA depuis 2001), je m’occupe des expertises sur les produits Oracle : SOCLE (Weblogic, Coherence, JRockit) SOA (Service Bus, SOA Suite, BPM)
MON CV
MAP
CULTURES
LIVRES
0 commentaires:
Enregistrer un commentaire