mardi 27 avril 2010

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

Question : quelle est l’influence d’une young generation ayant une taille trop grande

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

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 trop grande

Pour cette partie, nous maintenons la taille maximale du Heap à 16 MB.

Et nous fixons la taille de la « jeune génération » à 5,5 MB. (Souvenez-vous dans l’exemple précédent nous avons mis la jeune génération à seulement 1 Mo)

-XX:NewSize=5500k -XX:MaxNewSize=5500k -Xms16m -Xmx16m

La suite de la présentation est identique à ce qui a été fait précédemment

Lancer la démo Java2D

Lancer visualGC

- une fois l’application Java2D 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.

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

architecture soa, service oriented architecture, java software, open source, eclipse,alm, j2ee, java ,bpm

Pour cet exemple, nous avons eu 70 collections mineures (contre 160 dans l'exercice précédent), 48 collections complètes « full » (contre 16) et nous avons passé un total de 3 seconds. Bref, 3,33% (contre 1,66%) de la durée totale en GC.

(NB: ces chiffres différent selon la machine sur laquelle on exécute, mais la tendance est la même)

NB :

Il est à noter que pour cet exemple la jeune génération n’est pas de grande taille.

Interprétation

Notez que l’effet en dents de scie n’est plus clair. Vous pouvez remarquer également que l’application «saccade » en raison du fait que chaque GC mineur prend plus de temps (collection de 5,5 Mo au lieu de 1 Mo).

Même si vous avez moins de GC, ils prennent beaucoup de temps quand ils se produisent.

Pourquoi une jeune génération « trop grande » constitue un problème?

Si la jeune génération est trop grande, les pauses des collectes GC mineur risquent d’être plus longues (ce qu’on appelle Stop the world). Cela se manifeste, par exemple, par un  “affichage saccadée” pour les applications clientes.

NB : les valeurs fixés ont un but pédagogique d’illustration …

0 commentaires :

Enregistrer un commentaire

Architecte SOA & Professionnel Open Source Headline Animator

 
Khaled BEN DRISS
Cloud Computing, SOA et Web 2.0 : Des sujets techniques sur SOA et l'Open Source : de Java & .Net, PHP5, Symfony, à SaaS / PaaS en passant par Azure, google appengine, le BPM, la Modélisation et d'autres sujets du coté du serveur et cloud computing.