Tuning JVM et GC (Garbage collector) young generation : influence de la taille de la young generation (3/3)

Question : comment se manifeste l’effet d’une young generation de taille acceptable

Ce travail a été réalisé en collaboration avec Hamed KOUBAA, Architect SOA.

Introduction

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.

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.

Une jeune génération ayant la bonne taille

Dans cet exemple nous essayons de fixer la bonne taille de la jeune génération.

Rappelons que la valeur adéquate de la young generation dépend de l'application exécutée.

Il s'agit probablement d'une plage de valeurs acceptables.

Pour cet exemple, nous maintenons la taille maximale du Heap à 16 MB, mais nous fixons la jeune génération à 4 MB

-XX:NewSize=4m -XX:MaxNewSize=4m -Xms16m -Xmx16m

- une fois l’application lancée, 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. (à l’instar des autres exemples)

- ce qui suit est l’état de visualGC après une minute et demie d’observation

Interprétation

Si les temps de GC sont plus petite, cela peut signifier que nous avons réussi notre paramétrage (même si c’est encore tôt pour juger car la JVM peut bien se comporter dans des petit délais, puis elle change de comportement au cours de l’exécution)

Comment connaissez-vous que la jeune génération est bien ajuster?

Quand ce n'est pas trop petit ou trop grand ;-)

Bien entendu, la diminution des temps de CG est une bonne indication.

Remarques

Maintenant vous avez une compréhension des zones de mémoire HotSpot que vous avez réellement vu en exécutant Visual GC.

Vous avez une idée sur le paramétrage du young génération.

Astuce :

Pour Lignes directrices générales pour le dimensionnement de la jeune génération:

* Le ratio maximal entre la jeune génération (young generation) et le Heap ne doit pas dépasser les 45%

Si vous dépassez ce ratio alors il ya un risque que la jeune génération entière contient des objets vivants qu'ils ne pouvaient pas tous être promu à la old generation.

Généralement pour les applications clientes on commence par un pourcentage de 25%.

Pour les applications serveur on commence généralement par un pourcentage de 10% du Heap.

On augmente le taux selon les besoins.

Conclusion et perspectives :

Nous avons traités l’impact des principaux paramètres de la JVM

-XX:PermSize, -XX:MaxPermSize, -XX:NewSize, -XX:MaxNewSize, -Xms, -Xmx

une idée sur les indicateurs d’une JVM mal paramétrer : détecter quand le young generation, le old generation ou la permanet generation sont trop petit ou trop grand.

Plus la taille de la young generation est grande plus les collectes mineures sont rares.

Cependant, lorsque la taille du heap est peu extensible, cela va diminuer la taille de la tenured generation ce qui aura pour conséquence d'augmenter la fréquence des collectes majeures.

Un conseil :

L’étape suivante consiste à voir l’effet des autres paramètres de la JVM tq (disableExplicitGC, agressiveheap, printCompilation, concurrentGarbageCollection …Etc) utilisant d’autres exemples et en appliquant à votre application.