Tuning JVM et GC (Garbage collector) : La permanent generation

Question : quelle est le rôle de la permanent permanent generation

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

Permanent generation ?

Rappelons que la zone permanent generation définit une zone de mémoire qui accueille des objets permanents. Elle contient la définition des classes Java, qui sont chargées au démarrage de la JVM et au cours de l'exécution de l'application.

Il arrive parfois que cette zone soit trop petite et provoque un blocage de votre application. Dans ce cas le message de l'exception

• OutOfMemoryException : PermGen space.

Il n'y a pas de collectes dans cette zone.

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 - la JRE n'est pas suffisante.

Configurer les variables d’environnement JAVA_HOME

- télécharger si besoin visualgc .

Maintenant vous êtes prêt pour démarrer l’atelier.

Une génération permanente trop petite

Pour cet exercice, on réinitialise la taille maximale du Heap à notre standard de 16 MB. Nous gardons la jeune génération à notre optimale 4 MB.

Et maintenant, nous introduisons perm gen tuning en le fixant à 1 Mb.

-XX:PermSize=1m -XX:MaxPermSize=1m -XX:NewSize=4m -XX:MaxNewSize=4m -Xms16m -Xmx16m

- agrandir la fenêtre du java2D et observer le résultat

Le log de l’application montre qu’il y a une exception outOfMemory PerGen

Interprétation

Comment pouvez-vous savoir quand la permanent generation est trop petite?

Si l'application ne démarre pas ou se bloque avec une exception mémoire

Pourquoi une permanent generation qui est trop petit un problème?

Si la génération permanente est trop faible il n'y aura pas assez de place pour la JVM pour charger les bocaux et classfiles qui composent l'application elle-même.

La génération permanente est spéciale parce qu'elle contient des données utilisées par la machine virtuelle pour décrire les objets qui ne disposent pas d'une équivalence au niveau du langage Java. Par exemple, les objets décrivant les classes et les méthodes sont stockées dans la génération permanente.

Une génération permanente ayant la bonne taille

Maintenant nous avons fixé la permanent generation à 17 Mo (au lieu de 1 Mo pour l'exercice précédent). Le Heap d'ensemble et la taille des nouvelle génération reste la même à 16 Mo et 4 Mo, respectivement.

-XX:PermSize=17m -XX:MaxPermSize=17m -XX:NewSize=4m -XX:MaxNewSize=4m -Xms16m -Xmx16m

Interprétation :

Comment connaissez-vous la permanent generation a une taille adéquate?

Lorsque vous trouvez que le programme s'exécute avec une marge confortable de l'espace gen Perm.

Puis-je laisser la JVM déterminer la bonne taille permanent generation?

Bien sûr, en fait, vous pouvez définir les valeurs maximales de la permanent generation et laisser la JVM déterminer la taille adéquate selon le besoin, mais toujours sans dépasser cette taille max.

Pourquoi le tuning de la permanent generation est important?

Le tuning de la permanent generation est important si le contrôle de la consommation mémoire globale est important et que vous voulez obtenir un gain de performances supplémentaires en éliminant le temps de redimensionnement de la permanent generation.

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.

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

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 …

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

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.

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.

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

Une jeune génération trop petite

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 ….

Tuning JVM et GC (Garbage collector) : Avantages du "generational collection"

Un des avantages du "generational collection" est qu'il peut rendre les pauses causés par les GC plus courtes en ne rassemblant pas toutes les générations à la fois.

Rappelons que lorsque la demande d'allocation de mémoire ne peut être satisfaite,

• le GC déclenche d'abord "une collecte mineure", qui rassemble seulement la plus jeune génération. Puisque plusieurs des objets dans la jeune génération seront déjà morts (le collecteur copiant n'a pas besoin d'examiner les objets morts), les pauses mineures de GC peuvent être courtes et peuvent souvent reprendre un espace significatif du Heap.

• Si la collecte mineure libère assez d'espace du heap, le programme peut reprendre immédiatement.

• Mais, si ce n'est pas le cas, le GC procède à la collecte des générations plus élevées jusqu'à ce qu'assez de mémoire ait été reprise (une Full collection).

• Si le GC, ne peut reprendre assez de mémoire après une "Full collection", il augmentera la taille du heap, ou il lèvera une Erreur OutOfMemoryError

Les paramètres les plus connues sont :

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

-XX:PermSize	La taille de la génération permanente
-Xms	La taille initiale du Heap
-Xmx	La taille maximale du Heap
-XX:MinHeapFreeRatio	Pourcentage de l'espace libre minimum au sein d'une collection. Le GC accroît ou réduit la taille des collections pour tenter de préserver cette proportion. Par défaut elle est souvent de 40% (dépend de la plate-forme).
-XX:MaxHeapFreeRatio	Pourcentage de l'espace libre maximum au sein d'une collection. Le GC accroît ou réduit la taille des collections pour tenter de préserver cette proportion. Par défaut elle est souvent de 70% (dépend de la plate-forme).
-XX:NewRatio	Un ratio est utilisé qui indique le rapport entre la taille de la tenured gen et la young gen. Ce ratio est ensuite appliqué sur la valeur de l'option Xmx qui fixe la taille totale du heap. -XX:NewRatio=n ou n est un nombre entier. Si n vaut 3 alors la young gen est 3 fois plus petite que la tenured generation.
-XX:NewSize	Fixe la taille de la young gen -XX:NewSize = 4m fixe la taille la young generation à 4 MO.
-XX:MaxNewSize	Fixe la taille maximale de la young gen - XX:NewSize = 40m fixe la taille maximale la young generation à 40MO.

• Les commandes en –X ne sont pas documentées !!!

· java –X

Dans la suite nous allons montrer l’importance des choix des valeurs de certains de ces paramètres

Tuning JVM et GC (Garbage collector) : Rappel sur les generational garbage collectors

Question : quelle est la spécificité des GC (Garbage collector) générationnel

La technique employée pour les Garbage collector, depuis la JVM 1.2, est appelée "generational garbage collection" combine ces deux techniques pour tirer le meilleur parti des différents algorithmes du GC.

Ainsi, le heap (tas) est divisé en plusieurs zones basées sur l'âge d'un objet. Les différentes générations sont nettoyées (Garbage collection) séparément en utilisant des algorithmes de collection différents.

La mortalité enfantine des objets

L’idée est basée sur le constat de la mortalité enfantine des objets. La majorité des objets ont une durée de vie très courte "mortalité enfantine". Une étude statistique a montré que 80-98% des objets nouvellement alloués, meurent en quelques million d'instructions. Une autre a montré que 80-98% des objets nouvellement alloués, meurent avant qu'un autre Megabyte a été alloué.

Ce constat a un grand impact sur les algorithmes choisis pour le GC.

Generational collector

Ainsi un GC de type "Generational collector" divise le heap en plusieurs zones (générations).

Le objets sont créés, systématiquement, dans une zone dédiée dite young generation(dédié aux jeunes objets).

Les objets qui répondent à des critères de promotion, tels qu'avoir survécu à un certain nombre de collectes (lire GC), sont alors promus à la zone dédiée aux générations plus anciennes.

Cette zone est dite older generation (ou Tenured).

Un "generational collector" est libre d'employer une stratégie différente de collecte pour ses différentes zones et d'exécuter la collecte des "garbage" sur les générations séparément.

Dans la suite, nous utilisons les termes « anglais » afin de faciliter le lien avec les paramètres.

Le tuning de la JVM est le choix des paramètres

La JVM présente quelques dizaines de paramètres, permettant le tuning des performances.

Le plus important est de se fixer des objectifs et de conaitre sa cible.

Voici, quelques éléments à considérer, lors des choix des paramètres de chacune des zones mémoire constituant le Heap :

• Durée de Pause : Est ce que le collecteur arrête le programme pour réaliser la collecte (dit stop-the-world)? Pour combien de temps? Est ce que la durée des pauses peut être limitée ?

• Prédictibilité des pauses : Est ce les pauses causées par le GC peuvent être programmées à des périodes convenables à l'utilisateur du programme et non lorsque le GC le décide?

• Usage CPU : Quel pourcentage de la CPU est consommé par le GC?

• Utilisation de la Mémoire : Certains GC nécessite l'usage d'espace mémoire non accessible par l'utilisateur du programme, ce qui augmente la taille totale de la mémoire utilisée. La taille utilisée est supérieur à la mémoire nécessaire réellement au programme.

• Interaction avec la mémoire virtuelle : Pour les systèmes qui n'ont pas beaucoup de mémoire physique, une opération de GC peut nécessiter une interaction avec la mémoire virtuelle ce qui dégrade les performances.

• Interaction avec le Cache : Même pour les applications dont le heap peut résider dans la mémoire le GC aura comme impact de "flasher" les données utilisées par le programme, à cet instant, en dehors du cache, ce qui dégrade les performances

Suite de l’article sur les paramètres de la JVM, permettant le tuning des performances, dans les prochains postes ….

Ehcache 2.0 LE cache open source : Terracotta annonce la nouvelle version

Depuis peu sous le giron de Terracotta, Ehcache montre les signes d’un projet encore dynamique.

EHcache est le cache objet le plus populaire de la communauté open source. Son couplage avec Terracotta en fait une solution de cache de « classe entreprise ». EHcache est utilisé dans un vaste éventail d'applications pour booster les performances. Il est souvent associé à Hibernate. Il permet de décharger la base de données et simplifier la montée en charge.

J’ai eu le « plaisir « de l’activer (la version 1.2.3), récemment sur un projet :

· Aucun changement dans mon application (à part qq ligne sur la définition Hibernate)

· Des résultats immédiats : une amélioration nette des performances (l’application comporte un grand nombre de paramètres et de nomenclatures)

Bien que la version 1.x d’Ehcache soit robuste, éprouvée et complète des fonctionnalités, La nouvelle version Ehcache 2.0 était très attendue. Les améliorations les plus attendues sont :

• Le support de Hibernate 3.3 SPI caching plugin ›
• Le support de JTA ›
• La possibilité de changer la configuration dynamiquement à l’exécution avec JMX

Signalons la nouvelle offre apparue récement :ehcache-monitor (en beta)(décrit comme « ‘ Enterprise-class monitoring and management for development and production”

Ehcache est disponible sous la License Apache 2 et reste activement soutenu par Terracotta, Inc. Il est inclus dans l’offre de Terracotta scalability.

Terracotta souhaite « marquer son territoire » face à la montée de Jboss et son infinispan à ne pas confondre avec Jboss Cache.

Tuning des applications Java EE : Formation pratique au tuning de la JVM et Tomcat

Présentation

Dans le cadre de cycle de ATT (Advanced Technology Training), un nouveau workshop est programmé pour le 24/25 mars 2010, à Tunis.

Il s’agit workshop pratique sera dédié à une formation pratique au tuning de la Java Virtual Machine et destinée aux administrateurs d’applications Java et aux développeurs.

Ce Workshop intensif de 2 jours est le fruit de plusieurs années d’expérience de OXIA dans la mise en ouvre d’application Java EE et l’utilisation de Java dans un environnement serveur et pour des applications critiques (Banque, télécom …).

Son objectif est permettre à l’administrateur de serveurs d’applications Java EE, de mieux appréhender le tuning des applications Java (JVM) les volé technique et méthodologique. Les cas pratiques sont appliqués à Tomcat.

Les ateliers pratiques utiliseront des outils open source de profiling JVM et le serveur d’application, ainsi, que le paramétrage avancé, la résolution des remontées d’erreurs dans un environnement de production (inspiré de ITIL).

objectifs

Etre capable de choisir les paramètres de la virtual machine pour une application en production

Connaitre les étapes du Processus et Engineering de Performance

Connaitre les outils permettant de mettre ouvre le processus

Quelques sujets traités:

· Présentation de langage Java et Configuration de l’environnement

· Notion de Performance / Tuning

· Architecture de la JVM

· Options d’utilisation : les paramètres les plus importants

· Tuning de la JVM

· Gestion de la mémoire «Garbage collecting» : les générations

· Diagnostics : Gestion des erreurs

· Java en environnement de production :

· Container Web

· Serveurs d’applications

· Processus et Engineering de Performance

· Les étapes

· Comment faire ?

Les outils utilisés

Les ateliers utiliseront des outils open source pour :

· Etude du garabage collector

· Mesure de temps de réponse

· Simulation d’utilisateurs web et d’une montée en charge

· Profilers

· Etude du cycle de création des objets dans la JVM

· Détermination des fuites de mémoire

Lieu : Tunis Date : 24, 25 mars contact : info@oxia-group.com Tél : +21671282700

-----------------

Sujets sur l’étude de performance :

1. Est-ce que vous voulez connaitre ce que fait votre application coté base de données : employer un espion (open source)
2. Performance Engineering Process & Solutions (PEP&S) : Partie 2
3. La nouvelle version 3.0 de SOAPUI améliore le test des services REST
4. Performance Engineering Process & Solutions : PEP&S
5. Améliorer la performance de vos travaux de fin de journée par “JDBC Batch” et Spring
6. Application web : la différence entre Mesure de performance, montée en charge et vitesse d’exécution
7. Are the data from the GoogleApp Engine Dashbord valid?
8. Quel crédit donner aux résultats affichés par le DashBoard de GoogleApp Engine (GAE) ?
9. InfraRED : un outil de suivi des temps de réponse d’application J2EE, de monitoring et diagnostique de problèmes de performance.

Terracotta achète Ehcache: la concentration des projets open source s’accélère

Il y a quelques jours on a vue l’acquisition de Spring par Vmware, hier, 18 août 2009, c’est autour d’ EhCache de se faire « absorber » par Terracotta.

Ehcache une API de gestion de cache de donnée, est le projet open source le plus populaire dans la spécialité. EhCache est très connue par la communauté Java EE et spécialement par les utilisateurs de Hibernate et Spring.

Terracotta est une entreprise qui propose des solutions de clustering de JVM pour adresser les problématiques de haute disponibilité et de partage d’instance d’objets entre plusieurs JVM.

En quelques sortes Terracotta offre à l’application une mémoire distribuée sur toutes les JVM connectées (concept de Network Attach Memory).

Dans le mode open source Terracotta est en concurrence directe avec RedHat (JBoss Infinispan : open source Data Grid par la JBOSS).

Mais, la véritable concurrence vient des entreprises à code fermé, Oracle (Coherence) et GigaSpaces, et GemStone Systems.

Les deux sociétés sont issues du monde open source. Bien que techniquement logique, Il est probable que cet achat ne soit le prélude d’une préparation de la société à une vente.

Rappelons, que les deux solutions, Terracotta et ehcahe, s’intègrent parfaitement à Spring. Ça pourrait donner des idées à Vmware.

Mais ceci est un autre sujet

Twitter, Faut il envisager la vie sans : Twitter a subit sa première cyber-attaque

Twitter touché par un déni de service attaque DDOS : la nouvelle paru dans CNN il y a à peine quelques heures (CNN.com et reteurs ) , ce jeudi 06 juillet 2009.

L’attaque, coordonnée, sur Twitter a causé la fermeture du site de réseautage social, dit de microbloging, pour au moins deux heures.

En théorie cette attaque de twitter.com devrait, perturber uniquement les twitteurs.

Le principale problème, dans cette histoire, est que la panique généralisée a touché essentiellement les faceboukeurs dépendant (remarquons qu’avec l’addiction, il faut faire attention à la coupure brutale et envisager servage lors de toute thérapie …),

Trois points sont à retenir :

1. Twitter devient le talon d’Achille du réseautage social : La panique n’a pas touché seulement, les utilisateurs directs de Twitter, mais les utilisateurs des autres sites liés et référent twitter (un nombre croissant d’applications ping Twitter pour des infos). Ce type d‘attaque est accentué par les utilisateurs de twitter eux-mêmes qui en paniquant envoient plus de

http://lonewolflibrarian.files.wordpress.com/2009/05/twitterverse.jpg

( selon Lone Wolf Librarian)

2. Un site dépendant des services de twitter, comme FaceBook, doit être conçue en envisageant la vie sans : La place que prend twitter dans le paysage du réseautage social, devient de plus en plus handicapante pour les sites liés, lorsque l’architecte n’a pas envisagé quoi faire lorsque twitter est HS (hors service)

3. les infrastructures de twitter ont montré leur fragilité, twitter gagnerait à les renforcer en attendant de trouver le bon modèle économique pour les rentabiliser ...

Cette attaque sur twitter, n’est peut être qu’un exercice militaire, la suite cette été, comme ce qu’a subi l’Estonie, été 2007

Mais ceci est un autre histoire suivre, …

pour plus d’info

http://www.stumbleupon.com/s/#2IQI48/mashable.com/2009/08/06/twitter-outage//

http://www.stumbleupon.com/s/#2IQI48/mashable.com/2009/08/06/twitter-outage//

http://edition.cnn.com/2009/TECH/08/06/twitter.attack/index.html

http://www.reuters.com/article/rbssITServicesConsulting/idUSN0612153720090806

Monitoring web : LambdaProbe un super outil de monitoring de Tomcat : en open source et exploite JMX

Vous réalisez une application web sous Tomcat, utilisant ou non Spring, intégrant ou non JBPM ou d’autres moteurs de workflow, vous avez besoin d’un monitoring système ?

La solution : Lambda Probe

Lambda Probe est une application Web autonome, s’installe sur le serveur de production.

Lambda Probe permet de visualiser les différents paramètres de toutes les applications web installées dans Apache Tomcat.

Lambda Probe est est conçu spécialement et exclusivement pour fonctionner avec Tomcat.

page d’accueil de Probe

Le monitoring se fait en temps réel. Il offre la possibilité de consulter l'adresse IP de la session, la possibilité de consulter les servlets, les filtres, les Descripteurs cde ploiement.

Lambda Probe est en mesure d'accéder à toutes informations exposées par des agents JMX.

Si on click sur le lien de l’application « books » on accède à plusieurs paramètres de l’application tel que les sessions en cours, les pages JSP, les servlets, etc.

les sessions ouvertes sur l’application surveillé

Pour chaque session, nous avons accès aux objets qui se trouvent le dedans ainsi que d’autres informations tel que le type, la taille, la valeur de chaque objet.

Cette fonctionnalité permet de Controller le contenu de la session (elle met en exergue les objets non Serializable)

Utilisation de la mémoire par le serveur Tomcat

Attention n’a pas bougé depuis 28 Nov 2006

licence GPL

mais ceci est un autre sujet

-----------------

Sujets sur l’étude de performance :

1. Est-ce que vous voulez connaitre ce que fait votre application coté base de données : employer un espion (open source)

2. Performance Engineering Process & Solutions (PEP&S) : Partie 2

3. La nouvelle version 3.0 de SOAPUI améliore le test des services REST

4. Performance Engineering Process & Solutions : PEP&S

5. Améliorer la performance de vos travaux de fin de journée par “JDBC Batch” et Spring

6. Application web : la différence entre Mesure de performance, montée en charge et vitesse d’exécution

7. Are the data from the GoogleApp Engine Dashbord valid?

8. Quel crédit donner aux résultats affichés par le DashBoard de GoogleApp Engine (GAE) ?

9. InfraRED : un outil de suivi des temps de réponse d’application J2EE, de monitoring et diagnostique de problèmes de performance.

Monitoring : StackProbe : Un Profiler Java efficace, permet de comprendre ce qui se passe dans la JVM et exploite JMX

StackProbe est un outil pour la surveillance des applications Java: Il vous aide à trouver des fuites de mémoire et d'optimiser la vitesse.

Nécessite d’un profiler

Savoir ce qui se passe dans une application Java EE n’est pas chose facile, surtout lorsqu’on qu’on en dispose des documents d’architecture ni de la description de la structure des codes sources.

Mais, dans la majorité des situations, qu’on dispose du code source ou non, on a besoin d’inspecter ce qui ce passe réellement dans la JVM, qu’est ce qui se passe dans la JVM.

Un Profiler JVM est une solution de surveillance des applications Java qui vous permet de détecter, d'isoler et de diagnostiquer (d’une façon pro active) les problèmes de performance.

VisualVM, intègre à Java 6 de Sun, permet de savoir quelques informations.

NetBeans offre un profiler de qualité, et Eclipse n’arrive pas à simplifier l’installation de son TPTP.

Les outils commerciaux CA Wily Introscope ou ceux de HP Mercury sont légende dans la profession,

L’outil JProfiler est extrêmement populaire, mais nécessite d’être installé.

Mais, cette fois je présente un autre produit plus simple, sans installation : stackProbe

installer stackProbe

stackProbe est capable de profiler toute application java tournant sous le JDK 6.x de SUN.

Il suffit de le télécharger stackprobe.jar (120 kB !! ) et de lancer dans une JVM

java -jar stackprobe.jar

bien sûre après avoir obtenu une licence (StackProbe est un profiler commercial, il est gratuit pour les projets open source)

Il est possible de l’utiliser avec le service JNLP, ce qui permet d’utiliser toujours la dernière version stable disponible.

Le profiler : StackProbe

Il s’agit d’une inspection minutieuse de l’intérieur de la JVM.

Exemple : présentation des activités de Thread

Utiliser des filtres de type:

Présentation des activités des méthodes : on est capable de choisir le package pour isoler

• Thread-[0-9]+ pour "Thread-1", "Thread-2", ….
• com\.oxia\..* n’importe quelle méthode du package "com.oxia".

Présentation des résultats en suivant le chemin d’appelle des méthodes

Méthode : StackProbe utilise la méthode de sampling

StackProbe utilise la méthode de sampling, alors que la majorité des autres profiler utilisent l’instrumentation de bytecode.

Comment ça fonctionne :

StackProbe demande périodiquement à la JVM la liste des StackTraces pour tous les threads. Ces listes sont appelées échantillons. Plus l’application passe de temps dans une méthode, plus elle sera présente dans l’échantillonnage.

Le principal avantage de cette technique est que, même si elle présente une perturbation, cette surcharge est réparti également entre toutes les méthodes de l'application observée, il n'ya donc pas de risque d'introduction de faux goulets d'étranglement.

Le Profiler offre un panneau de paramétrages qui vous permet de régler le profilage à vos besoins.

L’avantage de StackProbe, c‘est qu’il n’a pas besoin d’être installé et il est capable d’inspecter la JVM sans instrumenter le code de l’application.

StackProbe ne fait pas la Détection et résolution de problèmes

Ce profiling, doit être intégré dès les premières phases d’un projet, ce qui permet d’anticiper les problèmes

Ce type outil doit être mis à la disposition de tous les développeurs et de l’équipe système, il pemrt d’offrir les données pour

Détection des fuites mémoire

La fuite mémoire apparait lorsqu'un objet n'est plus utilisé mais reste actif et ne peut être nettoyé par le GC.

Rechercher & donner des solutions pour les goulots d'étranglement de performances

Détecter et identifier quelle portion de code génère des problèmes de performances n'est pas une tâche simple et rapide.

Détecter & résoudre des « Deadlock »

Le < deadlock > est une condition ou des threads sont bloquées en attente d'entrer dans un bloc de synchronisation ou lorsque deux ou plusieurs threads s'exécutent simultanément et attendent les mêmes ressources.

Détecter la mauvaise utilisation de la mémoire

Détecter les objets qui utilisent d'une façon anormale plus de mémoire que nécessaire, sans qu'il y ait de fuite mémoire. Cette situation entraine une consommation excessive de la mémoire et engendre des besoins importants de swap.

Malheureusement, ce travail de détective reste à votre charge.

La solution de Profiling idéale devrait apporter, automatiquement, des solutions aux problèmes de performances du code

Mais ceci est un autre sujet.

d’autres sujets :

autres sujets traités :

1. Est-ce que vous voulez connaitre ce que fait votre application coté base de données : employer un espion (open source)

2. Performance Engineering Process & Solutions (PEP&S) : Partie 2

3. La nouvelle version 3.0 de SOAPUI améliore le test des services REST

4. Performance Engineering Process & Solutions : PEP&S

5. Améliorer la performance de vos travaux de fin de journée par “JDBC Batch” et Spring

6. Application web : la différence entre Mesure de performance, montée en charge et vitesse d’exécution

7. Are the data from the GoogleApp Engine Dashbord valid?

8. Quel crédit donner aux résultats affichés par le DashBoard de GoogleApp Engine (GAE) ?

9. InfraRED : un outil de suivi des temps de réponse d’application J2EE, de monitoring et diagnostique de problèmes de performance.

Est-ce que vous voulez connaitre ce que fait votre application coté base de données : employer un espion (open source)

Vous faites partie d’une équipe TMA ?

Vous avez hérité d’une application, suite au départ de votre collègue vers d’autres fonctions ?

Vous cherchez à cerner connaitre les requêtes lancés par JBPM ou Quartz, …

Et vous cherchez à cerner les causes de mauvais fonctionnement de votre application

La réponse est simple :

Utiliser un « mouchard » pour découvrir les requêtes SQL lancées par l’application vers la base de données.

L’installation est très simple

1) télécharge p6spy.jar ( le jar date de 2003, depuis il n’a pas évolué)

http://www.p6spy.com/survey.html

2) le fichier p6spy.jar doit être ajouté dans le classpath de l’application : pour une application Tomcat cela revient à mettre dans /web-inf/lib

3) Le fichier spy.properties doit être mis dans le même endroit que p6spy.jar.

a. dans la configuration de JDBC driver de l’application

i. changer le nom de driver réele par celui de p6spy.jar com.p6spy.engine.spy.P6SpyDriver

ii. mettre le « vraie » driver dans ce fichier realdriver=org.postgresql.Driver

Exemple avec JDBC Template de Spring

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"> <property name="driverClassName"> <value>com.p6spy.engine.spy.P6SpyDriver</value> </property> <property name="url"> <value>jdbc:postgresql://localhost/jsf</value> </property> <property name="username"> <value>jsf</value> </property> <!-- Make sure <value> tags are on same line - if they're not, authentication will fail --> <property name="password"> <value>password</value> </property> </bean>

Le résultat est immédiat

Lancer l’application

Un fichier spy.log sera crée dans le répertoire de base de l’application

Le log est de type

current time|execution time|category|statement SQL String|effective SQL string

1245846292012|15|0|statement|| select count(*) from client 1245846292012|-1||resultset| select count(*) from client |count = 0 1245846292090|0|1|statement||select label from article where id=1 1245846292090|-1||resultset|select label from article where id=1 |label = 1 1245846292168|0|2|statement||select * from client

Nous avons même le temps d’exécution en ms, ce qui permettra d’évaluer les temps de réponse …

Mais ceci est une autre histoire

Log File Format

The log file format of spy.log follows:

current time|execution time|category|statement SQL String|effective SQL string

• current time—The current time is obtained through System.getCurrentTimeMillis() and represents the number of milliseconds that have passed since January 1, 1970 00:00:00.000 GMT. (Refer to the J2SE documentation for further details on System.getCurrentTimeMillis().) To change the format, use the dateformat property described in Common Property File Settings.
• execution time—The time it takes for a particular method to execute. (This is not the total cost for the SQL statement.) For example, a statement SELECT * FROM MYTABLE WHERE THISCOL = ? might be executed as a prepared statement, in which the .execute() function will be measured. This is recorded as the statement category. Further, as you call .next() on the ResultSet, each .next() call is recorded in the result category.
• category—You can manage your log by including and excluding categories, which is described in Common Property File Settings.
• statement SQL string—This is the SQL string passed to the statement object. If it is a prepared statement, it is the prepared statement that existed prior to the parameters being set. To see the complete statement, refer to effective SQL string.
• effective SQL string—If you are not using a prepared statement, this contains no value. Otherwise, it fills in the values of the Prepared Statement so you can see the effective SQL statement that is passed to the database. Of course, the database still sees the prepared statement, but this string is a convenient way to see the actual values being sent to the database

Performance Engineering Process & Solutions (PEP&S) : Partie 2

Partie 2 : le processus

Les tests de performance doivent être implémentés et réalisés tout au long du cycle de développement.

Il est recommandé d’intégrer les mesures de performances dés les premières itérations :

- Tester le POC & l’architecture de base

- A 20 % du projet,

- A chaque jalon important

Le processus itératif se résume en :

Pour ce faire, nous mettrons en œuvre l’approche suivante pour chaque campagne de tests :

1. Identifier l'environnement de test : L'environnement de test doit être si possible identique à l’environnement de production. Pour cela, nous devons comprendre :

a. Le but de l'application web

b. Les comportements attendus des utilisateurs

c. L'architecture logique de l'application (n-tiers)

d. L'architecture physique de l'application (serveurs web, Base de données, etc.)

e. L'architecture réseau de l'application

2. Identifier les critères d'acceptation de performance

a. Déterminer les objectifs des tests (migration, tuning, etc.)

b. Estimer la valeur cible de l'usage des ressources et les seuils de tolérances

(Par exemple CPU < 75%, 1000 transactions/heure, etc.)

c. En déduire les métriques à utiliser (usage CPU, temps de réponse, usage mémoire, etc.)

3. Définir les scénarios : concevoir les tests

a. Identifier les principaux scénarii d'usage (les principaux use-cases) et les principaux chemins de navigation dans l'application.

b. Identifier les données à préparer pour que les tests soient réalistes (liste des clients, liste des produits, etc.)

c. Identifier les comportements des utilisateurs.

i. Identifier les erreurs classiques (lors des tests il est important de simuler les cas classiques d'erreurs des utilisateurs).

ii. Temps de réflexion (max, min, moyen).

4. Configurer l'environnement de test

a. Les outils de test utilisés

b. L'environnement d'exécution de l'application

5. Implémenter les tests : Enregistrer les scénarii

a. Les tests doivent être significatifs

i. Ne pas répéter la même transaction avec les mêmes données (résultats faussés à cause du cache de données)

ii. Ne pas générer des tests trop agressifs

6. Exécuter les tests

a. Valider les résultats des tests

i. Vérifier que le test fonctionne réellement

ii. Vérifier l'absence de problèmes qui faussent les résultats (réseau, disque, etc.)

b. Mesurer les réponses

c. Déterminer les lignes de base à utiliser pour évaluer les améliorations amenées par la variation d'un seul paramètre (mémoire, connexion JDBC, etc.)

d. Archiver les tests

7. Analyser les résultats

a. Synthétiser les résultats (plusieurs mesures doivent être réalisées pour prendre la moyenne, graphe de synthèse, etc.)

b. Rédiger un rapport : interprétation des résultats.

8. Optimiser le système

Place du PEP&S dans le cycle de développement des applications web

Tous les acteurs s'accordent sur la nécessité des Mesures de Performance et de leurs analyses, mais, les opinions divergent quand au moment.

La meilleure réponse est de rendre le PEP&S une partie intégrante du cycle de développement des applications web.

La mise en place du processus PEP& se résume en

• Évaluer le problème

• Mesurer le système

• Analyser les données

• Identifiez les goulots d'étranglement

• Optimiser le système

D’habitude, lorsque le chef de projet pense à réaliser une étude de performance il la planifie dans la phase de recette définitive. Or, la découverte d’un problème de performance à ce stade représente un danger pour le projet dans sa totalité. Il est important de planifier le suivi des performances dans les différentes phases du projet :

– Développement

• Profiling

• Logging

• Test Unitaire

– Assurance qualité / Staging

• Test fonctionnel

• Performance / test de charge

• blocage / tuning / amélioration de Performance

– Production

• Étude de la trace et vérification

• Disponibilité

• SLA (Service Level Agreements)

Le processus pourrait être résumé ainsi :

Il est recommandé de penser aux objectifs de performances très tôt :

– Fixer les cibles "lignes de base" /benchmarks

• Mettre en application une méthodologie qui permet la mesure des performances par rapport aux cibles "lignes de base" /benchmarks .

• Utiliser les bons outils.

• Construire des scripts de test "répétable" et automatisable.

autres sujets traités :

1. Est-ce que vous voulez connaitre ce que fait votre application coté base de données : employer un espion (open source)

2. Performance Engineering Process & Solutions (PEP&S) : Partie 2

3. La nouvelle version 3.0 de SOAPUI améliore le test des services REST

4. Performance Engineering Process & Solutions : PEP&S

5. Améliorer la performance de vos travaux de fin de journée par “JDBC Batch” et Spring

6. Application web : la différence entre Mesure de performance, montée en charge et vitesse d’exécution

7. Are the data from the GoogleApp Engine Dashbord valid?

8. Quel crédit donner aux résultats affichés par le DashBoard de GoogleApp Engine (GAE) ?

9. InfraRED : un outil de suivi des temps de réponse d’application J2EE, de monitoring et diagnostique de problèmes de performance.