Question : quelle est l’influence d’une young generation de petite taille
Ce travail a été réalisé en collaboration avec Hamed KOUBAA, Architect SOA.
L’objectif de cet atelier est de sensibiliser au choix des espaces mémoires de la JVM, basée sur un GC générationnel. Nous avons appliques au JDK de SUN.
Fixer la taille des zones mémoire de la JVM dépend de l’application, du cycle de création d’objets de l’application et nécessite une compréhension « détaillée» du fonctionnement du GC.
Les paramètres à donner à la JVM soutenant une d’une application Batch ne sont pas les mêmes que ceux d’une application web transactionnelle.
Afin d’illustrer les effets de la taille des zones mémoires de la JVM, nous avons délibérément utilisé un exemple simple et disponible : la fameuse démo Swing Java2D.
Le principe de l’atelier est simple : utiliser l’application java2D (inclus dans la jdk %java_home%/demo/jfc/Java2D) avec des paramètres différents de la JVM et interpréter les résultats obtenus.
pré requis
Les expérimentations de ce tutorial peuvent être réalisé sous Solaris, Linux et Windows : là où le JDK Hotspot de Sun fonctionne.
Il suffit d’Installer une JDK ultérieure à la version 5.0.
Les tests ont été réalisés avec JDK 1.0.0 build 17.
Noter que le JDK qui inclut des "démos" est nécessaire - un JRE n'est pas suffisant.
Configurer les variables d’environnement JAVA_HOME
- télécharger si besoin visualgc .
Maintenant vous êtes prêt pour démarrer l’atelier.
Manipulation des espaces mémoires de la jeune génération(young generation):
L’espace mémoire de la jeune génération (young generation) est constituer de la zone dite « Eden » plus deux espaces dits « survivor ».
L’objectif de cette partie de l’atelier est de savoir :
· Comment utiliser l’interface graphique de java perf pour lancer l'application Java 2D Demo et surveiller son rendement avec Visual GC.
· où trouver la ligne de commande qui règle les paramètres de la JVM
· Comment reconnaître si la jeune génération est trop petite, trop grande, avec une taille adéquate
Commencer par fixer la configuration suivante (appelé dans la suite LesCamandesGC)
-XX:NewSize=1m -XX:MaxNewSize=1m -Xms16m -Xmx16m -XX:MaxTenuringThreshold=0
Ces valeurs sont utilisées uniquement pour mettre l’accent sur les effets des paramètres du GC.
Lancer l'application Java 2D %java_home%/demo/jfc/Java2D avec cette commande
> java LesCamandesGC -jar Java2Demo.jar
- déterminer son identifiant de la machine virtuelle (VMID). La commande est « jps »
Ensuite utiliser ce VMID pour exécuter le programme jstat et recueillir des statistiques de base GC
- lancer l’application visual GC (télécharger si besoin visualgc ).
Visual GC donne un excellent aperçu de ce qui se passe dans la JVM. Lorsque vous combinez cette visualisation des statistiques supplémentaires recueillies pendant l'essai vous pouvez jauger la performance de l'application cible
L’application visualGC est composée de 3 volets :
1) Visual GC : Affiche les informations des applications de base comme le temps écoulé du processus et un certain nombre de statique (par exemple les options de ligne de commande).Notez que les zones d'écran représentant les Perm gen, Old gen, Eden et les espaces survivor (S0 et S1) sont dimensionnées proportionnellement à la capacité maximale des espaces.
2) Graph : Affiche des statistiques au fur et à mesure qu'elles évoluent dans le temps. Pour tous les exercices, l'intervalle d'échantillonnage a été choisie pour être une seconde.
3) Survivor Space histogramme : Le panneau histogramme affiche un aperçu de la répartition par âge des objets dans l'espace survivor actif après la dernière collection de la jeune génération. L'écran est composé de 32 régions de taille identique, un pour chaque âge objet possible.
Suite …
- Cliquez rapidement sur l’onglet transform > dans le carrée transform anim (celui en bas), augmenter le nombre d’objets de string et d’images animés au maximum.
Cette manipulation est importante pour obtenir l’effet recherché. En effet, les applications graphiques de l’onglet « transform » sont bien adaptés pour l'expérimentation du tuning de la JVM car ils créent beaucoup d'objets temporaires.
Faire un imprime-écran du visualGC après une minute et demie d’observation et essayer d’analyser le résultat.
Pour cet exemple, nous avons eu 160 collections mineures (c'est la jeune génération), 16 collections complètes « full » (c’est l'ancienne génération) et nous avons passé près de 1,5 secondes au garbage collection (cad un total de 1,66% de la durée totale en GC).
Interprétation :
Comment savoir si la jeune génération est trop petit?
| - Le premier indice est le pattern en dents de scie dans l’old generation. (NOTE: la vitesse à laquelle les objets sont générés dépend du matériel spécifique que vous utilisez ... Dans certains cas, ceci peut prendre plus temps pour se manifester .)
| 
|
| certains objets qui sont encore en vie sont directement promu vers l'ancienne génération (la jeune génération est trop petite …).
| 
|
- Un autre indice est le grand nombre de GC de type mineur, dans un petit espace de temps.
NB : Pour forcer l’observation de ce comportement, nous pouvons utilisé la config suivante ;
-XX:NewSize=1m -XX:MaxNewSize=1m -Xms16m -Xmx16m -XX:MaxTenuringThreshold=0
Pourquoi une jeune génération trop petite est un problème?
La collection des anciennes générations est généralement plus chère que les collections des jeunes générations.
En trouvant la taille appropriée de la jeune génération, on permet au GC mineurs, qui sont plus rapides, de nettoyer les objets temporaire en ne laissant passer que les objets encore vivant pour être promus en « old generation ».
NB : Vous pourriez vous demander, pourquoi ne nous fixons-XX: MaxTenuringThreshold = 0?
Avec ce paramétrage, nous demandons essentiellement à la JVM de promouvoir tout objet qui est vivant au cours d'un GC mineur à l’old generation.
à utiliser uniquement pour des besoins de démo!
Mais, pour des applications batch, où la majorité des objets sont “de type old” un MaxTenuringThreshold de petite taille peut aider ….
Articles
