Article technique

Cet article a été mis à jour pour inclure le logiciel GC Portal pour Linux et Java Desktop System (JDS), disponible à la fois pour Sun Java System Application Server 7 (anciennement Sun ONE Application Server 7 (S1AS7)) et les serveurs Tomcat. À l’origine, il n’était disponible que pour Solaris et Windows. Cette version du logiciel GC Portal comprend également VisualGC intégré au GC Portal.

Le GC Portal permet l’analyse et l’optimisation des performances des applications Java du point de vue de la collecte des déchets (GC) en exploitant les journaux verbose:gc générés par la JVM. GC Portal est une page unique pour les questions de GC et comprend une vaste collection de livres blancs, d’études de cas et d’autres documents. Le portail est destiné à être utilisé avec la JVM HotSpot de Sun Microsystems, distribuée dans le cadre de Java 2, Standard Edition (J2SE). L’utilisation du portail GC permet aux développeurs de modéliser les comportements de l’application et de la JVM dans une perspective GC. Cet article présente la conception et les fonctionnalités du GC Portal, afin de permettre aux développeurs de l’utiliser comme outil d’analyse et de réglage de la GC.

Le GC Portal nécessite l’utilisation des commutateurs suivants par la JVM pour la génération de verbose:gc journaux qui sont traités par le Portal pour analyse.

 -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 

Les autres commutateurs de la JVM ne sont pas tenus d’être utilisés pour générer les journaux appropriés pour le portail GC, mais ils peuvent être ajoutés selon ce qui est jugé approprié pour le réglage et le dimensionnement de la JVM et de l’application. Remarque : les commutateurs -XX sont non standard et sont également susceptibles d’être modifiés sans préavis dans les futures versions de la JVM.

Modélisation des applications et réglage des performances du point de vue de GC

La modélisation des applications Java permet aux développeurs de supprimer l’imprévisibilité attribuée à la fréquence et à la durée des pauses pour la collecte des déchets. Ces pauses sont directement liées à :

• Nombre et taille totale des objets créés et vivants
• Durée de vie moyenne de ces objets
• Taille du tas de la JVM

Sur la base de l’analyse fournie par le portail GC pour un ensemble spécifique de verbose:gc fichiers journaux alimentés sur le portail, les développeurs peuvent construire un modèle qui les aide à mieux comprendre le comportement de l’application et de la JVM.

Les journaux verbose:gc contiennent des informations précieuses sur :

• Les temps de pause GC
• Fréquence des GC
• Les temps d’exécution de l’application
• Taille des objets créés et détruits
• Taux de création d’objets
• Mémoire recyclée à chaque GC

Le comportement de l’application peut être représenté graphiquement et analysé pour déterminer les différentes relations entre la durée des pauses, la fréquence des pauses, le taux de création d’objets et la mémoire libérée. L’analyse de ces informations peut permettre aux développeurs de régler les performances d’une application, en optimisant la fréquence de la GC et les temps de collecte en spécifiant les meilleures tailles de tas, d’autres options de la JVM et des algorithmes alternatifs de GC pour une situation donnée.

Informations dérivées des journaux verbose:gc pour l’analyse et la modélisation du comportement de la GC

Ce type d’informations peut être utilisé pour régler les performances du processus de collecte des ordures.

Pauses GC moyennes dans la jeune et l’ancienne génération

Le temps moyen pendant lequel l’application est suspendue pendant que la collecte des ordures est effectuée dans la JVM.

Fréquence GC moyenne dans la jeune et l’ancienne génération

La périodicité à laquelle le ramasseur d’ordures s’exécute dans la jeune et l’ancienne génération. Ceci peut être obtenu puisque l’instance temporelle de chaque activité GC est enregistrée.

Surcharge séquentielle GC

Le pourcentage de temps système pendant lequel l’application est suspendue pour que le garbage collector ait lieu. Calculé comme suit : Avg. GC pause * Avg. GC * 100%

Surcharge concurrente GC

Le pourcentage de temps système pour lequel la collecte des déchets se produit en même temps que l’application. Calculé comme suit : temps de GC concurrent moyen (phase de balayage) * fréquence de GC concurrent moyen / nombre de CPU

Mémoire recyclée par chaque GC dans la jeune et l’ancienne génération

Le total des ordures collectées pendant chaque GC.

Taux d’allocation

Le taux auquel les données sont allouées par l’application dans la jeune génération. Si l’occupation du tas de la jeune génération_at_start_of_current_gc=x, l’occupation_at_end_of_previous_gc = y et la fréquence de GC est de 1 par seconde, alors le taux d’allocation est approximativement de x-y par seconde.

Taux de promotion

Le taux auquel les données sont promues à l’ancienne génération.

Données totales allouées par l’application

C’est le total des données qui sont allouées par l’application par transaction.

Les données totales peuvent être divisées en données à court terme et en données à long terme

Les données à long terme sont celles qui survivent aux cycles GC de la jeune génération et sont promues à l’ancienne génération.

Les données à court terme

Les données à courte durée de vie qui meurent très rapidement et sont collectées dans la jeune génération. Cela peut être calculé comme Données totales – Données à long terme.

Données totales actives

C’est le total des données vivantes à n’importe quelle instance du temps. Cette donnée est essentielle pour construire un modèle de dimensionnement du tas de la JVM. Par exemple, pour une charge de 100 transactions par seconde, avec des données à long terme de 50K par transaction qui durent au minimum 40 secondes, l’empreinte mémoire minimale de l’ancienne génération devrait être

50K*40s*100 = 200M

Fuites de mémoire

Celles-ci peuvent être détectées et les erreurs « out of memory » peuvent être mieux comprises en surveillant les ordures collectées à chaque balayage comme le montrent ces journaux.

Flags et commutateurs pour la génération de journaux GC

Il y a beaucoup d’informations utiles liées au GC que la JVM peut enregistrer dans un fichier. Ces informations sont utilisées par le portail GC pour régler et dimensionner les applications et la JVM du point de vue du GC. Les journaux contenant des informations détaillées sur le GC sont générés lorsqu’une application Java est exécutée avec les commutateurs suivants :

– verbose:gc Cet indicateur active la journalisation des informations sur le GC. Disponible dans toutes les JVM.

-XX:+PrintGCTimeStamps Imprime les heures auxquelles les GC se produisent par rapport au démarrage de l’application. Disponible uniquement à partir de J2SE1.4.0.

-XX:+PrintGCDetails Donne des détails sur les GC, tels que :

• Taille de la jeune et de la vieille génération avant et après les GC
• Taille du tas total
• Temps que prend une GC pour se produire dans la jeune et la vieille génération
• Taille des objets promus à chaque GC

Disponible uniquement à partir de JVM1.4.0.

Utilisation du portail GC pour la modélisation et le réglage des performances des applications

Le portail GC peut être utilisé pour mieux comprendre le comportement GC d’une application afin de régler les performances et de dimensionner les applications pour qu’elles s’exécutent de manière optimale dans des conditions de creux, de pic et de rafale. Il prend en charge les versions J2SE1.2.2, J2SE1.3, J2SE1.4 et J2SE1.4.1 et suivantes, y compris les deux nouvelles implémentations de garbage collection, le collecteur parallèle et le collecteur simultané. Il permet aux développeurs de soumettre des fichiers journaux GC et d’analyser le comportement des applications, sur la base de ces fichiers journaux. Il prend également en compte certaines informations spécifiques à l’application et à l’environnement, notamment :

• Transaction Rate or Server Load

  Cela s’applique aux applications typiques côté serveur fonctionnant dans une configuration Client-Serveur. Pour de telles applications, il s’agit du taux auquel le client pourrait générer une charge régulière que le serveur doit traiter et qui est utile pour une analyse en régime permanent du serveur. L’analyse de l’état stable peut inclure plusieurs scénarios tels que le pire cas/la situation de pointe/la situation de surcharge ou une situation moyenne. Ces informations ne sont pas obligatoires. Si elle n’est pas disponible ou pas applicable, elle peut être ignorée. Dans ce cas, certaines des informations présentées par le Portail doivent également être ignorées, qui comprennent :

  • Débit théorique
  • Données à court terme
  • Données à long terme

• Nombre de processeurs sur la machine cible

  Ces informations sont utilisées pour effectuer certains calculs par le Portail comme le surcoût de GC simultané.

• Version de JVM utilisée par l’application (1.2.2_xx, 1.3.x, 1.4.0, 1.4.1)

  Comme le format du journal verbose:gc n’est pas standard, et qu’il y a eu des changements de la JVM, cette information est nécessaire au portail GC.

Conception du portail GC

Le portail GC est composé de quatre moteurs :

• Moteur d’analyse et de rapport
• Moteur graphique
• Moteur d’intelligence
• Moteur de session et de stockage
• VisualGC

Moteur d’analyse et de rapport

• Charge les fichiers journaux verbose:gc, les exploite et produit des rapports :
  • Pause des CG dans la jeune et la vieille génération
  • Fréquence des CG dans la jeune et la vieille génération
  • Taux d’allocation des objets
  • Taux de promotion des objets. de la jeune à la vieille génération
  • Total GC time
  • Total Application time
  • Taille initiale et finale du tas de la jeune et de la vieille génération
  • Gain de temps séquentiel de la GC
  • . overhead
  • GC concurrent overhead
• Calcule et présente des informations liées à l’application
  • Données à court terme par transaction
  • Données à long terme par transaction
  • Débit maximum théorique
  • Efficacité de l’unité centrale

  Ces informations peuvent être ignorées pour les applications qui ne sont pas basées sur des transactions, mais elle est pertinente pour les applications côté client ou celles qui pourraient présenter un comportement extrêmement phasé.

• Présente le comportement détaillé lié au GC de l’application et de la JVM au fil du temps
  • L’utilisateur peut visualiser les données GC, échantillonnées à des intervalles de temps choisis pour l’ensemble de l’exécution.

  Ces informations détaillées sur le GC échantillonnées à des intervalles choisis pour l’ensemble de l’exécution sont extrêmement utiles lorsque les applications présentent un comportement varié au fil du temps, comme les applications phasées, cycliques ou à réaction aléatoire, et que les informations sommaires moyennes pourraient être faussées en conséquence. Ces informations détaillées et échantillonnées peuvent être utilisées pour voir le comportement de l’application et de la JVM tel qu’il évolue dans le temps.

• Informations détaillées sur le recyclage de la mémoire au fil du temps dans les jeunes et anciennes générations
  • Mémoire avant GC
  • Mémoire après GC
  • Mémoire libérée à chaque GC
• Informations sur le vieillissement des objets dans la jeune génération
  • Disponible si le commutateur -XX:+PrintTenuringDistribution est utilisé pour générer des journaux.

La figure 1 est un instantané d’un exemple de rapport présenté par le moteur d’analyse du portail GC.

Figure 1. Instantané du moteur d’analyse du portail GC

Moteur graphique

La plupart des informations qui sont présentées par le moteur d’analyse sous forme de tableau peuvent être tracées graphiquement. Plusieurs tableaux peuvent être tracés sur le même graphique pour faciliter les comparaisons.

• Présentation graphique de l’analyse détaillée de la chronologie de la GC
• Présentation graphique des informations de recyclage de la mémoire à chaque GC
• Comparaison graphique des informations de la GC à partir de divers fichiers journaux
• Présentation graphique des informations de tenure de l’âge des objets pour chaque « âge »

Figure 2. Instantané du moteur graphique du portail GC

Moteur d’intelligence

Le moteur d’intelligence est composé de :

• Recommandations générales

  Cette section fournit des documents couvrant des informations et des recommandations générales sur le réglage des performances du GC. Le portail ne fournit pas de recommandations dynamiques ni de réglage automatique. Les recommandations comprennent des informations générales sur la façon de :

  • Réduire la pause et la fréquence GC
  • Réduire la surcharge séquentielle GC
  • Dimensionner les tas de jeune et d’ancienne génération pour gérer une charge donnée
  • Détecter les fuites de mémoire
  • Choisir des collecteurs
  • Choisir différentes options et commutateurs JVM.
• Modélisation empirique

  Ranger l’application s’exécute en fonction des données analysées à partir de plusieurs verbose:gc journaux. L’utilisateur peut choisir les fichiers (parmi tous ceux qui ont été chargés) pour la modélisation en fonction des choix suivants :

  • Taux de transaction
  • Nombre de processeurs
  • Taille de la jeune génération
  • Taille de l’ancienne génération
  • Version du JDK
  • Taille du tas

  L’utilisateur peut classer l’environnement JVM optimal en fonction des critères suivants :

  • Pause de la JVM
  • Surcharge séquentielle de la JVM
  • Fréquence de la JVM
  • Efficacité de l’unité centrale

  L’utilisateur peut également visualiser la comparaison graphique des différentes exécutions.



Figure 3. Instantané du moteur d’intelligence du portail GC

• Projections pour le dimensionnement et le réglage à travers des scénarios « what-if »

  Comment le comportement du GC pourrait changer avec le changement de la taille de la jeune génération. Cette fonctionnalité est actuellement limitée et ne fonctionne qu’à partir de J2SE1.4.1 en utilisant le collecteur simultané. La sortie de projection montre les changements potentiels dans :

  • Pause du CG
  • Fréquence du CG
  • Charge séquentielle du CG
  • Utilisation de l’UCP (%)
  • Vitesse
  • Taux d’allocation
  • Taux de promotion
  • Taille des données de courte durée de vie
  • .vie
  • Taille des données à longue durée de vie

• Études de cas

  Quelques études de cas réels sur la façon de régler d’un point de vue GC.

• Livres blancs

  Pointeurs vers certains livres blancs avec des détails approfondis sur le tuning GC.

Moteur de session et de stockage

• Gérer les sessions des utilisateurs
• Gérer et stocker les profils des utilisateurs
• Gérer et stocker les données/journaux des utilisateurs en toute sécurité
• Rendre les journaux des utilisateurs/données disponibles pour une visualisation de référence, et une modélisation empirique

Figure 4. Instantané du moteur de stockage du portail GC

VisualGC

L’outil visualgc s’attache à une JVM HotSpot instrumentée et collecte et affiche graphiquement les données de performance du garbage collection, du chargeur de classes et du compilateur HotSpot. Il est incorporé au GC Portal pour recueillir des informations relatives à la collecte des déchets au moment de l’exécution de la JVM. GC Portal utilise l’outil webstart pour exécuter et afficher les informations du GC visuel dans un navigateur. Plus de détails sur cet outil sont disponibles sur la page CoolStuff – jvmstat. Le fichier ReadMe pour l’exécution de VisualGC à partir du GC Portal est intégré dans le logiciel GC Portal.

Remerciements:

L’auteur tient à remercier Mayank Srivastava, Nagendra Nagarajayya, Nandula Narasimham et S.R.Venkatramanan pour leur contribution au GC Portal. L’auteur souhaite également remercier les architectes et experts de la collecte des déchets des JVM de Sun, John Coomes, David Detlefs, Steve Heller, Peter Kessler, Ross Knippel, Jon Masamitsu, James Mcilree et Y.S. Ramakrishna, pour leur aide et leurs conseils sur ce travail. L’auteur souhaite également remercier les membres de l’équipe de performance JVM de Sun, Timothy Cramer et Brian Doherty (auteur des outils VisualGC et jvmstat) pour leur aide vers l’intégration de VisualGC dans GC Portal.

A propos de l’auteur:

Alka Gupta est membre du personnel technique de Sun Microsystems. Elle est chargée de travailler avec les ISV et les partenaires de Sun pour les aider à adopter rapidement et efficacement les technologies et plateformes émergentes de Sun. Elle travaille dans le domaine de l’optimisation des performances sur les plates-formes Sun depuis près de 7 ans, et évolue dans ce secteur depuis près de 10 ans. Alka est diplômée de l’Indian Institute of Technology (IIT), en Inde.