Optimisation de la machine virtuelle IBM pour Java
Un serveur d'applications est un serveur Java™ qui nécessite, à ce titre, un environnement JVM (machine virtuelle Java) pour l'exécution et la prise en charge des applications d'entreprise qui s'y exécutent. Lors de la configuration de votre serveur d'applications, vous pouvez configurer Java SE Runtime Environment afin d'optimiser les performances et l'utilisation des ressources système. Cette rubrique s'applique aux machines virtuelles IBM pour Java.
Avant de commencer
- Déterminez le type de machine JVM sur laquelle votre serveur d'applications est exécuté.
Exécutez la commande java –fullversion à partir du répertoire racine_serveur_app/java/bin de votre serveur d'applications.
En réponse à cette commande, Java consigne des informations relatives à la machine JVM, notamment sur son fournisseur, dans la fenêtre à partir de laquelle vous exécutez la commande. Par exemple :
java full version "JRE 1.6.0 IBM Windows 32 build pwi3260sr7-20091217_01 (SR7)"
En réponse à cette commande, Java consigne des informations relatives à la machine JVM, notamment sur son fournisseur, dans la sortie d'erreur standard.
Exécutez la commande dspwasinst à partir du répertoire racine_profil/bin Le résultat de cette commande contient le paramètre JAVA_HOME ainsi que d'autres informations relatives à la machine virtuelle Java activée pour votre profil de serveur d'applications.
Si votre serveur d'applications s'exécute sur une machine virtuelle Java Sun HotSpot, voir la rubrique Optimisation des machines virtuelles Java Sun HotSpot (Solaris & HP-UX).
Utilisez la commande managesdk, si vous souhaitez permettre à votre profil de serveur d'applications d'utiliser une autre machine JVM.
Vérifiez les points suivants :
- La version prise en charge la plus récente de la machine virtuelle Java est installée sur votre système.
- La mise à jour de service la plus récente est installée sur votre système. Presque tous les nouveaux niveaux de service améliorent les performances de la machine virtuelle Java.
Vérifiez que la mise à jour de service la plus récente est installée sur votre système. Presque tous les nouveaux niveaux de service améliorent les performances de la machine virtuelle Java.
Pourquoi et quand exécuter cette tâche
Chaque fournisseur JVM fournit des informations détaillées sur les performances et l'optimisation de sa machine JVM. Utilisez les informations de cette rubrique avec celles fournies avec la machine JVM qui s'exécute sur votre système.
Le contrôleur et le serviteur contiennent chacun une machine virtuelle Java. Les informations contenues dans la présente rubrique s'appliquent à la machine JVM du
serviteur. Il est généralement inutile de régler la machine JVM du contrôleur.
Un environnement d'exécution Java SE fournit l'environnement permettant d'exécuter les applications d'entreprise et les serveurs d'applications. C'est pourquoi la configuration Java joue un rôle significatif dans la détermination des performances et de l'utilisation des ressources système pour un serveur d'applications et les applications associées.
La machine virtuelle IBM pour Java version 6.0 inclut les spécifications Java EE (Java Platform, Enterprise Edition) les plus récentes et améliore les performances ainsi que la stabilité des versions précédentes de Java.
Même si l'optimisation des machines virtuelles Java dépend du fournisseur de machine virtuelle Java que vous utilisez, il existe des concepts d'optimisation généraux valables pour toutes les machines virtuelles Java. Ces concepts généraux sont les suivants :
- Optimisation du compilateur. Toutes les machines JVM utilisent des compilateurs JIT (Just-In-Time) pour compiler les codes d'octet Java en instructions natives lors de l'exécution du serveur.
- Optimisation du segment de mémoire ou de la mémoire Java. L'optimisation de la fonction de gestion de la mémoire JVM ou de la fonction de récupération de place constitue un bon point de départ pour améliorer les performances de la machine JVM.
- Optimisation du chargement des classes.
- Optimisation des performances de démarrage et d'exécution
La procédure suivante donne des instructions spécifiques sur la façon d'exécuter les types de réglage suivants pour chaque machine JVM. Vous pouvez exécuter les étapes dans n'importe quel ordre.
Procédure
Limitez le nombre de clichés pris dans des situations spécifiques.
Dans certaines conditions d'erreur, il se peut que plusieurs unités d'exécution de serveur d'applications échouent et que la machine virtuelle Java demande un TDUMP pour chacune de ces unités d'exécution. Si un nombre significatif d'unités d'exécution échoue simultanément, le nombre résultant d'opérations TDUMP simultanées peut entraîner d'autres incidents avec le système, notamment un manque d'espace de stockage secondaire. Utilisez la variable d'environnement JAVA_DUMP_OPTS pour spécifier le nombre de clichés que vous souhaitez que la machine JVM effectue dans certaines situations. La valeur indiquée pour cette variable n'affecte pas le nombre d'opérations TDUMP générées à cause des appels com.ibm.jvm.Dump.SystemDump() provenant des applications qui sont exécutées sur le serveur d'applications.
Par exemple, si vous souhaitez configurer la machine JVM de sorte qu'elle :- limite le nombre d'opérations TDUMP à une,
- limite le nombre d'opérations JAVADUMP à trois maximum,
- ne capture pas la documentation si un événement INTERRUPT se produit,
alors attribuez à la variable JAVA_DUMP_OPTS la valeur suivante :JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE)
- Optimisez les performances de démarrage et d'exécution.
Dans certains environnements, tel qu'un environnement de développement, il est plus important d'optimiser les performances de démarrage de votre serveur d'applications que les performances d'exécution. Dans d'autres environnements, il est plus important d'optimiser les performances d'exécution. Par défaut, les machines virtuelles IBM pour Java sont optimisées pour les performances d'exécution tandis que les machines virtuelles Java HotSpot sont optimisées pour les performances de démarrage.
Le compilateur JIT (Just-in-Time) Java à une incidence sur l'optimisation des performances de démarrage et d'exécution. Le niveau d'optimisation initial utilisé par le compilateur a un impact sur la durée de compilation d'une méthode de classe et la durée de démarrage du serveur. Pour des démarrages plus rapides, réduisez le niveau d'optimisation initial utilisé par le compilateur. Si, toutefois, vous réduisez le niveau d'optimisation initial, les performances d'exécution de vos applications peuvent se dégrader car les méthodes de classe sont maintenant compilées à un niveau d'optimisation inférieur.
- -Xquickstart
Ce paramètre influence la manière dont la machine virtuelle IBM pour Java utilise un niveau d'optimisation inférieur pour les compilations des méthodes de classe. Un niveau d'optimisation inférieur permet des démarrages plus rapides du serveur mais nuit aux performances d'exécution. Si ce paramètre n'est pas spécifié, la machine virtuelle IBM pour Java démarre par défaut avec un niveau d'optimisation initial élevé pour les compilations, ce qui se traduit par de meilleures performances d'exécution, mais des démarrages plus lents du serveur.
Vous pouvez définir cette propriété sur le panneau de la machine virtuelle Java à l'aide de la console d'administration. Pour en savoir plus, voir les informations sur les paramètres de la machine virtuelle Java.
Information valeur Valeut par défaut Niveau d'optimisation initial du compilateur élevé Recommandé Niveau d'optimisation initial du compilateur élevé Utilisation Spécifiez -Xquickstart pour améliorer la durée de démarrage du serveur.
Pour accélérer l'initialisation de la JVM et améliorer la durée de démarrage du serveur, définissez les arguments de ligne de commande suivants dans la zone Arguments de la machine JVM généraux dans la section Propriétés générales de l'onglet Configuration.
-Xquickstart -Xverify:none
- -Xquickstart
- Configurez la taille des segments de mémoire.
Les paramètres du segment Java ont une incidence sur le comportement de la fonction de récupération de place. L'augmentation de la taille des segments permet de créer plus d'objets. Du fait qu'un segment de grande taille met plus de temps à se remplir, l'application dispose d'une autonomie plus importante et les opérations de récupération de place sont moins fréquentes. Cependant, plus la taille du segment est importante, plus il faut de temps pour le compresser et plus le processus de récupération de place est long.
La machine JVM utilise des seuils définis pour gérer le stockage alloué. Lorsque les seuils sont atteints, le programme de récupération de place est appelé pour libérer l'espace de stockage non utilisé. Par conséquent, la récupération de place peut entraîner une dégradation non négligeable des performances Java. Avant de changer les tailles de segment initiale et maximale, prenez en compte les informations suivantes :- Dans la plupart des cas, vous devez donner à la taille de segment JVM maximale une valeur supérieure à celle de la taille de segment JVM initiale. Cette valeur permet à la machine JVM de fonctionner efficacement au cours de périodes normales et stables au sein du segment de mémoire initial. Elle permet également à la machine JVM de fonctionner efficacement au cours de périodes caractérisées par un volume élevé de transactions car la machine JVM peut étendre le segment jusqu'à la valeur spécifiée pour la taille de segment JVM maximale. Dans quelques rares cas où les performances optimales absolues sont requises, il serait préférable d'attribuer la même valeur à la taille de segment initiale et maximale. Cette valeur permet d'éliminer la relative surcharge observée lorsque la machine JVM étend ou réduit la taille du segment JVM. Avant de modifier les tailles de segment de la machine JVM, vérifiez que l'allocation de mémoire de la machine JVM est assez importante pour accommoder la nouvelle taille de segment.
- N'attribuez pas une taille de segment initiale trop grande car, si cela améliore au départ les performances en retardant la récupération de place, le processus de récupération affecte le temps de réponse lorsque la récupération de place est lancée, étant donné que le processus doit fonctionner plus longtemps.
Notez que les informations du segment Java se trouvent dans des enregistrements SMF et peuvent être consultés dynamiquement à l'aide de la commande DISPLAY,JVMHEAP de la console.
Pour configurer la taille des segments mémoire à l'aide de la console d'administration :
- Dans la console d'administration, cliquez sur Serveurs>Types de serveurs > Serveurs d'applications WebSphere > nom_serveur.
Dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
Dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus.
Sélectionnez Contrôle ou Serviteur, puis Machine virtuelle Java.
- Entrez une nouvelle valeur dans la zone Taille initiale du
segment ou Taille maximale du segment.
Vous pouvez aussi entrer des valeurs dans ces deux zones afin de régler les deux paramètres.
Pour l'analyse des performances, les tailles initiale et maximale du segment doivent être égales.
Le paramètre Taille initiale du segment Java indique la quantité de mémoire, en mégaoctets, allouée au segment de mémoire de la machine JVM au démarrage de cette dernière. Le paramètre Taille maximale du segment indique la quantité de mémoire maximale, en mégaoctets pouvant être allouée au segment de mémoire de la machine JVM. Ces deux paramètres ont une incidence non négligeable sur les performances.
Lors de l'optimisation des réglages d'un système de production dans lequel vous ignorez la taille de la partie active des applications d'entreprise qui s'exécutent sur le système, 25 % de la taille maximale du segment constitue une valeur de départ appropriée pour la taille initiale du segment. La machine JVM essaie ensuite d'adapter la taille du segment à celle de la partie active de l'application.
L'illustration suivante représente trois profils d'utilisation des processeurs. La charge de travail est la même pour les trois profils, mais chacun reflète un paramétrage différent du segment Java. Pour le profil intermédiaire, les tailles initiale et maximale du segment est de 128 Mo. Quatre processus de récupération de place sont mis en oeuvre. Le temps total passé à récupérer de la place est égal à environ 15 % du temps total d'exécution. Lorsque la taille du segment est doublée à 256 Mo, comme dans le profil du haut, une augmentation du temps de travail utile est constatée entre les opérations de récupération de place. Seules trois opérations de récupération de place ont été effectuées, mais leur durée a augmenté. Dans le troisième profil, la taille du segment Java est réduite à 64 Mo et on constate l'effet inverse. Avec un segment plus petit, l'intervalle entre deux opérations de récupération de place est plus court et ces opérations sont elles-mêmes plus courtes. Dans les trois cas, le temps total consacré à la récupération de place est approximativement égal à 15 % du temps total d'exécution de l'essai. Cet exemple illustre un concept important du segment Java et de sa relation avec l'utilisation des objets. Les opérations de récupération de place ont toujours une incidence sur l'exécution des applications d'entreprise.
Exécutez une série de tests qui font varier les réglages. Par exemple, effectuez des tests avec des valeurs de 128 Mo, 192 Mo, 256 Mo et 320 Mo. Lors de chaque essai, surveillez la quantité totale de mémoire utilisée. Si vous augmentez la taille du segment dans des proportions trop importantes, il est possible que vous observiez un début de pagination mémoire.
Pour identifier les phénomènes de pagination, utilisez la commande vmstat ou l'Analyseur de performances de Windows. En cas de pagination, réduisez la taille du segment Java ou ajoutez de la mémoire au système.
Utilisez la commande IBM i WRKSYSSTS pour rechercher la pagination. En cas de pagination, réduisez la taille du segment Java ou ajoutez de la mémoire au système.
En cas de pagination, réduisez la taille du segment Java ou ajoutez de la mémoire au système.
Une fois tous les essais terminés, comparez les statistiques suivantes :- Nombre d'appels d'opération de récupération de place.
- Durée moyenne d'un appel d'une seule opération de récupération de place.
- Rapport entre la longueur d'un appel d'une seule opération de récupération de place et la durée moyenne entre les appels.
Si l'application ne fait pas un usage excessif des objets et ne présente pas de fuite de mémoire, elle atteint un état d'utilisation stable de la mémoire. La récupération de place est mise en oeuvre moins fréquemment et pour des durées plus courtes.
Si l'espace disponible dans le segment est de 85 % ou plus, envisagez de réduire les valeurs de taille maximale du segment car la mémoire allouée à ce dernier est sous-utilisée par le serveur d'applications et l'application.
Si vous disposez de serveurs configurés pour s'exécuter en mode 64 bits, vous pouvez leur affecter une taille de segments mémoire sensiblement supérieure à celle par défaut. Par exemple, vous pouvez spécifier une taille de segments de mémoire maximale initiale de 1844 Mo pour le contrôleur et le serviteur si le serveur est configuré pour fonctionner en mode 64 bits.
- Cliquez sur Valider.
- Cliquez sur Sauvegarder pour sauvegarder les modifications apportées à la configuration principale.
- Arrêtez, puis redémarrez le serveur d'applications.
Vous pouvez aussi utiliser les arguments de la ligne de commande pour régler ces paramètres. Ils sont valables pour toutes les machines virtuelles Java prises en charge et permettent d'ajuster les tailles de segment minimale et maximale pour chaque serveur d'applications ou instance de serveur d'applications.
- -Xms
Ce paramètre contrôle la taille initiale du segment de mémoire Java. L'optimisation de ce paramètre réduit la durée des opérations de récupération de place et améliore ainsi le débit et le temps de réponse du serveur. Pour certaines applications, la valeur par défaut de cette option peut s'avérer trop faible, ce qui entraîne un nombre élevé d'opérations de récupération de place mineures.
Information valeur Valeut par défaut 50 Mo Recommandé Spécifique à la charge de travail, mais généralement plus élevée que la valeur par défaut. Utilisation La spécification de -Xms256m définit une taille de segment initiale de 256 Mo. - -Xmx
Ce paramètre contrôle la taille maximale du segment de mémoire Java. L'augmentation de la valeur de ce paramètre augmente la mémoire à la disposition du serveur d'applications et réduit la fréquence de récupération de place. Une telle augmentation peut améliorer le temps de réponse et le rendement du serveur. Elle se traduit toutefois par l'augmentation de la durée des récupérations de place. La valeur de ce paramètre ne doit jamais excéder la mémoire système dont dispose l'instance du serveur d'applications. L'attribution à ce paramètre d'une valeur supérieure à la mémoire système disponible peut entraîner la pagination système et une dégradation importante des performances.
Information valeur Valeut par défaut Par défaut, la machine virtuelle Java calcule automatiquement la taille du segment de mémoire Java en fonction de la mémoire disponible dans le système. Recommandé Spécifique à la charge de travail, mais généralement plus élevée que la valeur par défaut, selon la quantité de mémoire physique disponible. Utilisation La spécification de -Xmx512m définit une taille maximale de segment de mémoire de 512 Mo. Eviter les incidents: Indiquez une valeur pour le paramètre -Xmx pour réduire les risques de saturation de mémoire.gotcha
-Xlp
Utilisez ce paramètre avec la machine virtuelle IBM pour Java afin d'allouer le segment de mémoire si vous utilisez de grandes pages, d'une taille de 16 Mo par exemple. Avant de spécifier ce paramètre, vérifiez que votre système d'exploitation est configuré pour prendre en charge les grandes pages. L'utilisation de grandes pages peut réduire la durée d'utilisation de l'UC requise pour garder une trace du segment de mémoire et peut également autoriser la création d'un segment de mémoire plus grand.
Valeut par défaut 64 ko, si vous utilisez Java 8 –Xlp64k
Ce paramètre peut être utilisé pour allouer le segment de mémoire à l'aide de pages de taille moyenne, par exemple 64 ko. L'utilisation de cette taille de page de mémoire virtuelle requise par une application peut améliorer les performances et le rendement des applications grâce à l'efficacité du matériel associée à une taille de page plus importante.
i5/OS et AIX fournissent un support enrichi de page de 64 Ko environ, car les pages de 64 Ko sont des pages générales. Les pages de 64 ko peuvent être aisément activées et les applications peuvent y gagner en performances. Il est possible de modifier ce paramètre sans modifier la configuration du système d'exploitation. Toutefois, il est recommandé d'exécuter vos serveurs d'applications dans un pool de stockage distinct si vous utilisez des pages de 64 ko.
Recommandé Utilisez si possible la taille de page de 64 ko. Les systèmes i5/OS POWER5+ et i5/OS Version 6, édition 1 prennent en charge les pages de 64 Ko.
Les systèmes POWER5+ et AIX 5L version 5.3 avec le nécessaire de maintenance recommandé 5300-04 prennent en charge la taille de page de 64 Ko lors de l'exécution du noyau 64 bits.
–Xlp4k
Ce paramètre peut être utilisé pour allouer le segment de mémoire à l'aide de pages de 4 ko. L'utilisation de cette taille de page de mémoire virtuelle requise par une application, à la place de 64 ko, peut avoir un impact négatif sur les performances et le débit de l'application en raison des insuffisances matérielles qui sont associées à une taille de page inférieure.
Le paramètre d'allocation de segment de mémoire Java peut être modifié sans avoir à changer la configuration du système d'exploitation. Toutefois, il est recommandé d'exécuter vos serveurs d'applications dans un pool de stockage distinct si vous utilisez des pages de 64 ko.
Recommandé Utilisez si possible -Xlp64k à la place de -Xlp4k.
- Optimisez la mémoire Java. Les applications d'entreprise écrites en langage Java utilisent souvent un grand nombre d'objets aux relations complexes. Bien que le langage Java gère automatiquement la mémoire associée aux cycles de vie d'un objet, il est important de bien comprendre de quelle manière l'application utilise les objets. En particulier, assurez-vous qu'il existe les conditions suivantes :
- L'application n'utilise pas les objets de façon excessive.
- L'application ne perd pas d'objets.
- Les paramètres de segment Java sont définis de manière à prendre en charge un mode d'utilisation d'objet donné.
- Identifiez l'utilisation excessive d'objets.
Vous pouvez passer en revue les compteurs associés à l'exécution de la machine virtuelle Java et inclus dans les rapports Tivoli Performance Viewer, afin de déterminer si une application utilise de façon excessive des objets. Vous devez définir l'option de ligne de commande -XrunpmiJvmtiProfiler, ainsi que le niveau maximal du module JVM, afin d'activer les compteurs JVMTI (Java Virtual Machine Profiler Interface).
L'intervalle moyen des opérations de récupération de place doit de préférence représenter 5 à 6 fois la durée moyenne d'une seule opération de récupération de place. Si vous ne respectez pas cette durée, l'application passe plus de 15 % de son temps en récupération de place.
Vous pouvez vérifier si l'application utilise les objets de manière excessive en consultant les compteurs d'exécution de la JVM. Vous devez définir l'option de ligne de commande -XrunpmiJvmtiProfiler, ainsi que le niveau maximal du module JVM, afin d'activer les compteurs JVMTI (Java Virtual Machine Profiler Interface). L'intervalle moyen des opérations de récupération de place doit de préférence représenter 5 à 6 fois la durée moyenne d'une seule opération de récupération de place. Si vous ne respectez pas cette durée, l'application passe plus de 15 % de son temps en récupération de place.
Si les valeurs observées démontrent qu'il y a un goulet d'étranglement, il existe deux remèdes possibles à cette situation. Le moyen le plus simple et le plus efficace d'optimiser l'application consiste à implémenter des caches et des pools d'objets. Utilisez un profileur Java pour déterminer quels objets sont concernés. Si vous ne pouvez pas optimiser l'application, essayez d'ajouter de la mémoire, des processeurs et des clones. Le surcroît de mémoire permet à chaque clone de disposer d'une taille de segment Java (tas) raisonnable. Quant aux processeurs supplémentaires, ils permettent aux clones de fonctionner en parallèle.
- Testez l'existence de fuites de mémoire.
Dans le langage Java, les fuites de mémoire sont souvent à l'origine de goulets d'étranglement provoqués par la récupération de place. Elles génèrent plus de dommages que l'utilisation excessive de mémoire, car elles finissent par entraîner une instabilité du système. Au fil du temps, la récupération de place se produit plus fréquemment, puis le segment Java finit par s'épuiser et le code Java échoue sur une exception de type Mémoire insuffisante (Out of Memory). Les fuites de mémoire se produisent lorsqu'un objet inutilisé possède des références non libérées. Cela arrive le plus souvent dans les classes de collecte telles que Hashtable, car la table elle-même contient toujours une référence à l'objet, même lorsque les références réelles à cet objet ont été supprimées.
Une charge de travail élevée entraîne souvent l'arrêt des applications après leur déploiement dans l'environnement de production. Si une application subit des fuites de mémoire, une charge de travail élevée peut accélérer le grossissement de la fuite et provoquer des incidents d'allocation de mémoire.
Le test des fuites de mémoire a pour but d'amplifier les chiffres. Les fuites de mémoire sont mesurées en fonction du volume d'octets et de kilo-octets non récupérable par le biais de la fonction de récupération de place. La tâche la plus délicate consiste à différencier ce volume de données et la taille attendue de mémoire utile et non utilisable. Elle est plus facile à exécuter lorsque les valeurs sont plus élevées, ce qui génère des écarts plus importants et facilite l'identification des incohérences. La liste suivante offre un aperçu de la manière d'interpréter les résultats de votre test de fuite de mémoire :- Test de longue durée
Les incidents liés à des fuites de mémoire peuvent se manifester tardivement et c'est pourquoi les fuites de mémoire sont détectées facilement au cours de tests de longue durée. Les tests courts peuvent fournir des indications non valides de l'emplacement des fuites de mémoire. Il est souvent difficile de déterminer à quel moment une fuite de mémoire se produit dans le langage Java, en particulier dans le cas d'une augmentation subite ou progressive de l'utilisation de la mémoire pendant un intervalle de temps donné. Les fuites de mémoire sont difficiles à détecter car ces types d'augmentation peuvent être valides ou voulues par le développeur. Pour faire la différence entre des objets dont l'utilisation est retardée et des objets totalement inutilisés, vous devez exécuter les applications pendant une période plus longue. Le fait de tester les applications sur une période plus longue permet de déterminer avec certitude si l'utilisation des objets est retardée ou non.
- Test répétitif
Dans de nombreux cas, les incidents liés aux fuites de mémoire se produisent lors d'exécutions répétées d'un même scénario de test. Le test des fuites de mémoire a pour but d'établir une distinction importante entre la mémoire non utilisable et la mémoire utilisée en terme de taille relative. En répétant plusieurs fois le même scénario, cet écart s'accroît progressivement. Ce test est utile si le nombre de fuites provoquées par l'exécution d'un scénario de test est tellement limité qu'il serait presque passé inaperçu lors d'une exécution unique.
Vous pouvez utiliser des tests répétitifs au niveau du système ou du module. Les tests modulaires offrent de meilleures possibilités de contrôle. Lorsqu'un module est conçu pour conserver le module privé sans générer d'effets secondaires, tels que l'utilisation de la mémoire, le test des fuites de mémoire peut s'effectuer plus facilement. L'utilisation de la mémoire avant l'exécution du module est enregistrée. Une série déterminée de scénarios de test est ensuite exécutée de manière répétitive. A la fin de l'exécution des tests, l'utilisation de la mémoire en cours est enregistrée et contrôlée afin de repérer tout changement significatif. Il convient de proposer l'exécution de la récupération de place lors de l'enregistrement de l'utilisation réelle de la mémoire en insérant System.gc() dans le module où doit s'effectuer la récupération de place ou en utilisant un outil de profilage dans le but de forcer le déclenchement du processus.
- Test de concurrence
Certains incidents liés aux fuites de mémoire peuvent se produire uniquement lorsque plusieurs unités d'exécution sont actives dans l'application. Malheureusement, des fuites de mémoire sont susceptibles de se produire aux points de synchronisation en raison de la complexification de la logique du programme. Une programmation hasardeuse peut entraîner la conservation ou la non-libération de références. Une augmentation des accès concurrents favorise ou accélère les incidents liés aux fuites de mémoire. La manière la plus répandue d'augmenter les accès simultanés consiste à accroître le nombre de clients dans le pilote de test.
Tenez compte des facteurs suivants lors de la sélection des scénarios de test à utiliser pour tester les fuites de mémoire :- Un scénario de test efficace met en oeuvre les sections de l'application dans laquelle les objets sont créés. Dans la plupart des cas, il est nécessaire de connaître le fonctionnement de l'application. Une description du scénario peut suggérer la création d'espaces de données, tels que l'ajout d'un enregistrement, la création d'une session HTTP, l'exécution d'une transaction et la recherche d'un enregistrement.
- Recherchez les zones dans lesquelles les collections d'objets sont utilisées. En règle générale, les fuites de mémoire sont composées d'objets appartenant à la même classe. De plus, les classes de collection, telles que Vector et Hashtable, sont des emplacements où sont généralement stockées de manière implicite les références à des objets par l'appel aux méthodes d'insertion correspondantes. Par exemple, la méthode get d'un objet Hashtable ne supprime pas ses références à l'objet extrait.
Vous pouvez utiliser Tivoli Performance Viewer pour vous aider à détecter des fuites de mémoire.
Pour des résultats optimaux, répétez l'essai en augmentant à chaque fois la durée, avec des demandes de 1000, 2000 et 4000 pages. La courbe Tivoli Performance Viewer de la mémoire utilisée doit être en dent de scie. Chaque point de la courbe correspond à une opération de récupération de place. Votre application présente une fuite de mémoire dans les cas suivants :
- La quantité de mémoire utilisée immédiatement après chaque opération de récupération de place chute notablement. Si cette condition se produit, la courbe en dent de scie ressemble plus à un escalier.
- La courbe en dent de scie est de forme irrégulière.
- La différence entre le nombre d'objets alloués et le nombre d'objets libérés augmente dans le temps.
Si la consommation de segments de mémoire semble indiquer une fuite de mémoire lorsque le serveur d'applications utilise régulièrement près de 100 % du processeur, mais que la situation se normalise lorsque la charge de travail est plus légère ou presque nulle, les segments de mémoire sont fragmentés. La fragmentation des segments peut se produire lorsque la JVM peut libérer un nombre suffisant d'objets pour répondre aux demandes d'allocation de mémoire au cours des cycles de récupération de place, mais ne dispose pas du temps nécessaire pour compresser des zones de mémoire disponible de petite taille afin de générer des espaces contigus de plus grande taille.
Une autre forme de fragmentation des segments se produit lorsque des objets de moins de 512 octets sont libérés. Les objets sont libérés mais l'espace mémoire n'est pas restauré, ce qui provoque une fragmentation de la mémoire qui dure jusqu'à ce qu'une compression soit effectuée.
La fragmentation des segments de mémoire peut être réduite en forçant les compressions, mais les performances s'en font ressentir. Utilisez la commande Java -X pour consulter la liste des options de mémoire.
- Test de longue durée
- Optimisez la récupération de place
La machine virtuelle Java utilise en parallèle un programme de récupération de place afin de tirer parti d'un processus SMP lors de la plupart des cycles de récupération de place.
L'examen de la récupération de place Java indique comment l'application utilise la mémoire. La récupération de place est un avantage offert par Java. Le développeur étant soulagé de la partie gestion de la mémoire, les applications Java sont plus fiables que celles qui sont écrites dans d'autres langages où la récupération de place n'est pas prévue. L'application ne doit cependant pas abuser des objets. La récupération de place consomme généralement entre 5 et 20 % du temps d'exécution total d'une application dont l'exécution se déroule correctement. Si ce processus n'est pas géré, la récupération de place peut devenir l'un des plus gros goulets d'étranglement d'une application.
La surveillance de la récupération de place lors de l'exécution d'une charge de travail fixe, indique si l'application surutilise les objets. La récupération de place peut même détecter la présence de fuites de mémoire.
Vous pouvez configurer le type et le comportement de la récupération de place avec des paramètres JVM. Lorsque la machine JVM ne peut pas allouer un objet du segment en cours en raison du manque d'espace contigu, le programme de récupération de place est appelé pour redemander la mémoire des objets Java qui ne sont plus utilisés. Les fournisseurs de machines JVM proposent des règles de programme de récupération de place et des paramètres d'optimisation qui leur sont propres.
Vous pouvez utiliser le paramètre de récupération de place en mode prolixe dans la console d'administration pour activer le contrôle de la récupération de place. La sortie de ce paramètre inclut des statistiques sur la collecte des classes pour libération mémoire. Le format du rapport généré n'est pas normalisé entre les différentes machines virtuelles Java ou niveaux d'édition.
Pour régler les paramètres de récupération de place JVM :
- Dans la console d'administration, cliquez sur Serveurs>Types de serveurs > Serveurs d'applications WebSphere > nom_serveur.
Dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
Entrez l'option –X à modifier dans la zone Arguments JVM génériques .
Dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Serviteur.
Dans la section Propriétés supplémentaires, cliquez sur Entrées d'environnement.
Ajoutez l'entrée d'environnement IBM_JAVA_OPTIONS, ou modifiez-la, de la façon suivante.
- Si l'entrée d'environnement IBM_JAVA_OPTIONS existe, modifiez-la pour ajouter l'option –X Java à ajouter à la valeur existante.
- Sinon, cliquez sur Nouveau pour créer une nouvelle entrée d'environnement.
Entrez les valeurs suivantes dans les zones correspondantes du formulaire :
Information valeur Nom : IBM_JAVA_OPTIONS Valeur : Option –X Java à ajouter Description : Description de cette option.
Cette procédure met à jour le fichier was.env dans le répertoire de configuration de WebSphereApplication Server. Les paramètres sont appliqués aux régions serviteur, de contrôle et auxiliaires.
- Cliquez sur Valider.
- Cliquez sur Sauvegarder pour sauvegarder les modifications apportées à la configuration principale.
- Arrêtez, puis redémarrez le serveur d'applications.
La liste ci-après répertorie les options –X pour les différents programmes de récupération de place JVM.
- Le récupérateur de place de la machine virtuelle IBM pour Java.
- Un guide complet de l'implémentation IBM du récupérateur de place Java est fourni dans le manuel IBM SDK, Java Technology Edition, Version 8 User Guide.
L'option Java -X permet d'afficher la liste des options de mémoire.
- -XgcpolicyLa machine virtuelle IBM pour Java met à disposition quatre règles de récupération de place. Chacune offre des avantages uniques.Remarque : Bien que chaque règle offre des avantages, pour WebSphere Application Server Version 8.0 et les versions suivantes, gencon est la règle de récupération de place par défaut. Les versions antérieures du serveur d'applications indiquent que optthruput est la règle de récupération de place par défaut.
- gencon est la règle par défaut. Cette règle fonctionne avec le récupérateur de place générationnel. Le schéma générationnel tente d'atteindre un débit élevé avec des durées de pause de récupération de place réduites. Pour ce faire, le segment de mémoire est divisé en ancien et nouveau segments. Les objets à durée de vie longue sont promus à l'ancien espace alors que ceux à durée de vie courte font l'objet d'une récupération de place rapide dans le nouvel espace. La règle gencon offre des avantages considérables pour la plupart des applications. Toutefois, elle n'est adaptée que pour certaines d'entre elles et s'avère généralement plus difficile à optimiser.
- La règle optthruput offre un débit élevé, mais elle est associée à des durées de pause plus importantes lors de la récupération de place. Pendant cette dernière opération, toutes les unités d'exécution de l'application sont arrêtées pour le marquage, le balayage et la compression lorsque celle-ci est requise. La règle gencon suffit pour la plupart des applications.
- La règle optavgpause réduit les durée de pause de récupération de place en effectuant les phases de marquage et de balayage de la récupération de place lors de l'exécution de l'application. Cette règle a peu d'incidence sur le débit global.
- La règle subpool augmente les performances sur les systèmes multiprocesseur qui utilisent couramment plus de 8 processeurs. Cette règle est disponible uniquement sur les processeurs IBM System i System p et System z. La règle subpool est identique à la règle gencon, mais le segment de mémoire est divisé en sous-portion de mémoire permettant une meilleure évolutivité pour l'affectation d'objet.
Information valeur Valeut par défaut gencon Recommandé gencon Utilisation La spécification de Xgcpolicy:gencon permet de définir gencon comme règle de récupération de place. Si vous affectez à gcpolicy la valeur gencon, le marquage simultané est désactivé. Les meilleurs débits devraient être obtenus avec la règle gencon, à moins que vous n'obteniez des temps de réponse erratiques, ce qui indique de possibles problèmes de durée de la pause.
Si vous affectez à gcpolicy la valeur optavgpause la marque concurrente est activée avec ses valeurs par défaut. Ce paramètre réduit les temps de réponse erratiques des applications provoqués par les opérations normales de récupération de place. Toutefois, cette option peut réduire le débit global.
- -Xnoclassgc
Par défaut, la machine JVM décharge une classe de la mémoire lorsqu'il ne reste plus d'instances actives de cette classe. Le temps système requis pour charger et décharger plusieurs fois la même classe peut réduire les performances.
Eviter les incidents: Vous pouvez utiliser l'argument -Xnoclassgc pour désactiver la collecte des classes pour libération mémoire. Toutefois, l'incidence sur les performances de la collecte des classes inutilisées est généralement minime, et désactiver cette collecte dans un système basé sur Java EE (Java Platform, Enterprise Edition) avec une utilisation intensive des chargeurs de classes d'application, peut effectivement entraîner une fuite de mémoire des données des classes et provoquer l'émission par la JVM d'une exception de saturation de mémoire.
Si vous utilisez cette option, à chaque fois que vous redéployez une application, vous devez toujours redémarrer le serveur d'applications afin de supprimer les classes et les données statiques de la version précédente de l'application.
gotchaInformation valeur Valeut par défaut La récupération de place occupée par les classes est activée. Recommandé Ne désactivez pas la collecte des classes pour libération mémoire.
Utilisation Vous pouvez utiliser -Xnoclassgc pour désactiver la collecte des classes pour libération mémoire.
- -Xgcpolicy
- Activez la mise en cache du nom de système hôte local Par défaut dans le kit de développement de logiciels IBM pour
Java, la méthode statique java/net/InetAddress.getLocalHost ne met pas ses résultats en cache. Cette méthode est utilisée partout dans WebSphere Application
Server, et notamment dans les agents d'administration tels que le gestionnaire de déploiement et l'agent de noeud. Si l'adresse du système hôte local d'un processus ne change pas au cours de son exécution, il est conseillé d'utiliser un cache intégré pour la recherche du système hôte local en associant la propriété système com.ibm.cacheLocalHost à la valeur true. Consultez la rubrique relatives aux propriétés personnalisées de la machine virtuelle Java dans le centre de documentation pour des instructions de définition des propriétés personnalisées JVM pour les divers types de processus.
Eviter les incidents: Les adresses des serveurs configurés avec DHCP changent au fil du temps. Ne définissez pas cette propriété à moins que vous n'utilisiez des adresses statiques pour votre serveur.gotcha
Information valeur Valeut par défaut com.ibm.cacheLocalHost = false Recommandé com.ibm.cacheLocalHost = true (voir la description) Utilisation La spécification de -Dcom.ibm.cacheLocalHost=true active le cache getLocalHost - Activez la partage de classes dans une mémoire cache.
L'option de classe partagée permet de partager des classes dans un cache. Ce partage peut réduire la durée de démarrage ainsi que l'utilisation de la mémoire. Les processus, tels que les serveurs d'applications, les agents de noeud et les gestionnaires de déploiement peuvent utiliser l'option de classes partagées.
Cette option est activée par défaut dans le serveur d'applications. Pour vider la mémoire cache, appelez l'utilitaire racine_serveur_app/bin/clearClassCache ou arrêtez le serveur d'applications, puis relancez-le.
Si vous utilisez cette option, vous devez vider le cache lorsque le processus n'est pas utilisé. Pour vider la mémoire cache, appelez l'utilitaire racine_serveur_app/bin/clearClassCache.bat/sh ou arrêtez le processus, puis relancez-le.
Remarque : Si vous utilisez clearclasscache, pour effacer l'intégralité du cache, vous devez arrêter toutes les machines virtuelles Java associées.Pour désactiver l'option des classes partagées pour un processus, entrez l'argument JVM -Xshareclasses:none pour ce processus :
- Dans la console d'administration, cliquez sur Serveurs>Types de serveurs > Serveurs d'applications WebSphere > nom_serveur.
Dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
Dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus.
Sélectionnez Contrôle ou Serviteur, puis Machine virtuelle Java.
- Entrez -Xshareclasses:none dans la zone Arguments JVM génériques.
- Cliquez sur OK.
- Cliquez sur Sauvegarder pour sauvegarder les modifications apportées à la configuration principale.
- Arrêtez, puis redémarrez le serveur d'applications.
Information valeur Valeut par défaut L'option Share classes in a cache est activée. Recommandé Laissez l'option Share classes in a cache activée. Utilisation Spécifiez -Xshareclasses:none pour désactiver l'option Share classes in a cache. Activez les références condensées sur les environnements 64 bits.
Vous pouvez activer les références condensées sur les environnements 64 bits, tels que AIX 64, Linux PPC 64, zLinux 64 et Microsoft Windows AMD64, Linux AMD64.
Vous pouvez également activer les références condensées sur les environnements IBM i 64 bits tels qu'IBM i Version 6.1.
L'option des références condensées fournie dans l'implémentation IBM de JRE (Java SE Runtime Environment) version 6.0 permet de limiter l'ensemble des références mémoire à une taille de 32 bits. En règle générale, les machines virtuelles Java 64 bits utilisent plus d'espace au niveau du segment de mémoire que les machines virtuelles Java 32 bits du fait qu'elles utilisent des références mémoire étendues 64 bits pour adresser la mémoire. Le segment de mémoire adressable par la référence 64 bits est bien plus grand que le segment de mémoire 32 bits mais, dans la réalité, un segment qui requiert la totalité des 64 bits pour l'adressage n'est généralement pas requis. La compression des références réduit la taille des adresses et permet d'utiliser de façon plus efficace le segment. La compression de ces références améliore également le cache du processeur et l'utilisation du bus, et de ce fait les performances.
Eviter les incidents: gotcha
La fonction des références condensées n'est pas prise en charge sur :- la machine virtuelle Java HP-UX 64 bits,
- la machine virtuelle Java iSeries 64 bits classique
Pour permettre à une machine virtuelle Java 64 bits de s'exécuter en mode de références condensées, une nouvelle variable d'environnement doit être indiquée dans la configuration de WebSphereApplication Server. Dans la console d'administration :
- Cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere > nom_serveur.
- Cliquez sur l'onglet Configuration. Sous Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > serviteur.
- Dans la section Propriétés supplémentaires, cliquez sur Entrées d'environnement.Ajoutez l'entrée d'environnement IBM_JAVA_OPTIONS, ou modifiez-la, de la façon suivante :
- Si vous voyez une entrée d'environnement nommée IBM_JAVA_OPTIONS, éditez-la pour ajouter l'option Java –Xcompressedrefs à la valeur existante.
- Sinon, cliquez sur Nouveau pour créer une nouvelle entrée d'environnement. Entrez les valeurs suivantes dans les zones correspondantes du formulaire :
Information valeur Nom : IBM_JAVA_OPTIONS Valeur : -Xcompressedrefs Description : Active le mode de références condensées 64 bits.
Cette procédure met à jour le fichier was.env dans le répertoire de configuration de WebSphereApplication Server. Les paramètres sont appliqués aux régions serviteur, de contrôle et auxiliaires.
Eviter les incidents: Lorsque vous indiquez Xcompressedrefs comme argument JVM générique, WebSphereApplication Server ne peut pas démarrer en raison d'une erreur d'option Java non prise en charge. Si l'application nécessite un segment de mémoire de plus de 30 gigaoctets, le mode 64 bits par défaut doit être utilisé.gotcha
Le produit active automatiquement la compression de pointeur sur les plateformes prises en charge par défaut si la taille du segment de mémoire (contrôlée par le paramètre -Xmx) est inférieure à une taille donnée (environ 25 Go selon la plateforme utilisée) ou utilise par défaut les références non condensées. L'utilisateur peut ignorer ces valeurs par défaut à l'aide des options de ligne de commande ci-après.
Remarque : WebSphere Application Server for z/OS n'active pas automatiquement la compression de pointeur. Il est conseillé aux utilisateurs de l'activer manuellement à l'aide des options de ligne de commande.
Remarque : Pour Java 8 SR2 FP10, ou pour z/OS Java 8 SR3, l'option -Xcompressedrefs est activée par défaut jusqu'à 57 Go et peut être utilisée avec des valeurs supérieures en fonction de la plateforme.Les options de ligne de commande suivantes permettent de contrôler la fonction des références condensées :- -Xcompressedrefs
- Cette option de ligne de commande permet d'activer la fonction des références condensées. Lorsque la machine virtuelle Java est lancée avec cette option de ligne de commande, elle utilise les références mémoire étendues 32 bits pour adresser le segment de mémoire. Cette fonction peut être utilisée jusqu'à une taille de segment donnée (environ 29 Go selon la plateforme utilisée), contrôlée par le paramètre -Xmx.
- -Xnocompressedrefs
- Cette option de ligne de commande permet de désactiver de façon explicite la fonction des références condensées. Lorsque la machine virtuelle Java est lancée à l'aide de cette option de ligne de commande, elle utilise les références mémoire étendues 64 bits pour adresser le segment de mémoire. Cette option peut être utilisée pour ignorer l'activation par défaut de la compression de pointeur, le cas échéant.
- Optimisez le processus de mise à jour de la configuration pour une configuration de cellule de grande taille. Dans une configuration de cellule de grande taille, vous devrez peut-être déterminer ce qui est le plus important : les performances de mise à jour de configuration ou le contrôle de cohérence. Le gestionnaire de déploiement gère une configuration principale pour la totalité de la cellule. Par défaut, lorsque la configuration est modifiée, le produit compare la configuration dans l'espace de travail au référentiel maître pour que l'espace de travail reste cohérent. Toutefois la vérification de la cohérence peut accroître la durée nécessaire pour sauvegarder une modification de la configuration ou déployer un nombre important d'applications. Les facteurs suivants jouent sur cette durée :
- Plus le nombre de serveurs d'applications ou de clusters dans une cellule est élevé, plus il faut de temps pour enregistrer une modification de la configuration.
- Plus le nombre d'applications dans une cellule est élevé, plus il faut de temps pour enregistrer une modification de la configuration.
Si le temps nécessaire pour changer une modification apportée à la configuration n'est pas satisfaisant, vous pouvez ajouter la propriété personnalisée config_consistency_check à vos paramètres JVM et attribuer à cette propriété la valeur false.- Dans la console d'administration, cliquez sur Administration du système > Gestionnaire de déploiement.
- Dans l'infrastructure de serveur, sélectionnez Java et Gestion des processus, puis cliquez sur Définition de processus.
- Sous Propriétés supplémentaires, cliquez sur Machine virtuelle Java > Propriétés personnalisées> Nouveau.
- Entrez config_consistency_check dans la zone Nom et false dans la zone Valeur.
- Cliquez sur OK, puis sauvegardez ces modifications dans la configuration maître.
- Redémarrez le serveur.
Configurations prises en charge: La propriété personnalisée config_consistency_check modifie uniquement le processus du gestionnaire de déploiement. Elle n'affecte pas les autres processus et notamment ceux de l'agent de noeud et du serveur d'applications. La vérification de la cohérence n'est pas effectuée sur ces processus. Toutefois, dans les fichiers SystemOut.log de ces processus, une remarque peut indiquer que la vérification de la cohérence est désactivée. Pour ces processus de gestionnaire non lié au déploiement, vous pouvez ignorer ce message.sptcfg
Si vous utilisez la commande wsadmin wsadmin -conntype none en mode local, vous devez attribuer la valeur false à la propriété config_consistency_check avant d'émettre la commande.
Que faire ensuite


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_tunejvm_v61
Nom du fichier : tprf_tunejvm_v61.html