Paramètres de la machine virtuelle Java

83.29/3724.32 * 100 = 2,236 %

Si plus de 5 % de votre temps est consacré à la récupération d'espace mémoire et si celle-ci se produit fréquemment, vous devez augmenter la taille du segment Java.

Pour déterminer si la taille de tas alloué augmente, étudiez le pourcentage du tas qui n'est pas alloué après chaque cycle de récupération de place, puis vérifiez que le pourcentage ne continue pas à diminuer. Si le pourcentage d'espace disponible continue à diminuer, c'est que vous rencontrez une augmentation progressive de la taille du tas de la récupération de place à la récupération de place. Cette situation peut indiquer qu'une fuite de mémoire est présente dans votre application.

Spécifiez -DhotRestartSync si vous souhaitez activer la fonction de synchronisation au redémarrage à chaud du service de synchronisation. Cette fonction indique au service de synchronisation que l'installation s'exécute dans un environnement où les mises à jour de configuration n'ont pas lieu lorsque le gestionnaire de déploiement n'est pas actif. Par conséquent, au redémarrage du gestionnaire de déploiement ou de l'agent de noeud, le service n'a pas besoin d'effectuer de comparaison complète avec le référentiel. L'activation de cette fonction optimise l'efficacité de la première opération de synchronisation après le redémarrage du gestionnaire de déploiement ou d'un agent de noeud, en particulier pour les installations comportant des cellules de versions différentes, utilisant plusieurs noeuds et exécutant plusieurs applications.

Affectez à cette option la valeur true pour activer la fonction AES (Advanced Encryption Standard) fournie avec Runtime Environment for AIX, Java Technology Edition, Version 7. AES est un algorithme par bloc de chiffrement qui chiffre et déchiffre les données en plusieurs passes. L'activation de cette fonction améliore les performances dans le traitement SSL WebSphere Application Server.

Vous pouvez utiliser -Xverify:none pour sauter l'étape de vérification de classe au cours du chargement de classes. L'utilisation de -Xverify:none désactive la vérification de classe Java, ce qui améliore de 10 à 15 pour cent le temps de démarrage. Cependant, si cet argument est indiqué, les données de classe endommagées ou non valides ne sont pas détectées. Si des données de classe endommagées sont chargées, la machine virtuelle Java peut avoir un comportement inattendu, ou les opérations effectuées avec cette machine peuvent échouer.

Eviter les incidents :

• N'utilisez pas cet argument si vous effectuez des modifications du code intermédiaire, car les opérations effectuées avec la machine JVM peuvent échouer si une erreur d'instrumentation se produit.
• Si vous rencontrez un échec au niveau de la machine JVM ou si cette machine JVM présente des comportements inattendus lorsque cet argument est utilisé, la première étape à effectuer pour le débogage du problème lié à la machine JVM consiste à désactiver cette option.
• IBM i ne prend pas en charge cet argument.

gotcha

Vous pouvez utiliser -Xnoclassgc pour désactiver la collecte des classes pour libération mémoire. Cet argument augmente la réutilisation des classes et améliore légèrement les performances. Toutefois, les ressources appartenant à ces classes restent utilisées même lorsque les classes ne sont pas appelées.

Eviter les incidents : L'incidence sur les performances de la récupération de place des donnée de classe est généralement minime et la désactivation de cette fonction dans le système de base Java Platform, Enterprise Edition (Java EE), qui utilise intensivement les chargeurs de classe, peut générer une fuite de mémoire des données de classe et amener la machine JVM à émettre une exception.gotcha

Vous pouvez utiliser le paramètre de configuration verbose:gc pour contrôler la récupération de place. Vous pouvez utiliser la sortie obtenue pour déterminer l'impact des performances sur la récupération de ces ressources.

Si vous spécifiez l'argument -Xnoclassgc, 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 précédente version de l'application.

Eviter les incidents : IBM i ne prend pas en charge cet argument. Vous devez utiliser l'argument -noclassgc pour désactiver la collecte des classes pour libération mémoire sur cette plateforme.gotcha

Vous pouvez utiliser -Xgcthreads pour utiliser simultanément plusieurs unités d'exécution de récupération de place. Cette technique de récupération de place est appelée récupération de place parallèle. Cet argument est valide uniquement pour IBM Developer Kit.

Lorsque vous indiquez cette valeur dans la zone Arguments JVM génériques, indiquez aussi le nombre de processeurs qui s'exécutent sur votre machine.

Définissez -Xgcthreads comme suit :

-Xgcthreads<nombre de processeurs>

Eviter les incidents : N'insérez pas d'espace entre --Xgcthreads et la valeur n de nombre de processeurs.

-Xgcthreads5 est un exemple de définition de -Xgcthreads avec 5 processeurs.

gotcha

Pratiques recommandées : Utilisez la fonction de récupération de place parallèle si votre machine est équipée de plusieurs processeurs.bprac

Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha

Vous pouvez utiliser -Xnocompactgc pour désactiver la compression des tas de mémoire. La compression des tas de mémoire est l'opération de récupération de place la plus coûteuse. Si vous utilisez IBM Developer Kit, évitez d'utiliser la compression de segment de mémoire. Si vous désactivez la fonction de compression de segment, vous éliminez toutes les surcharges qui lui sont associées.

Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha

Définissez -Xgcpolicy pour définir la règle de récupération de place. Cet argument est valide uniquement pour IBM Developer Kit.

Associez cet argument à la valeur optthruput si vous voulez optimiser le rendement. Cela ne crée aucun problème si des pauses de récupération de place longues surviennent.

Affectez à cet argument la valeur gencon si vous utilisez un collecteur de récupération de place. 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 dans 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.

Définissez cet argument sur optavgpause, si vous souhaitez que le marquage simultané soit utilisé pour analyser les unités d'exécution de l'application à partir de la pile avant même que le tas soit saturé. Si ce paramètre est spécifié, les pauses du récupérateur de place deviennent uniformes, et les pauses longues ne sont pas apparentes. Cependant, l'utilisation de cette règle permet de réduire le rendement car les unités d'exécution pourraient avoir des tâches supplémentaires à effectuer.

Affectez à cet argument la valeur subpool pour améliorer les performances sur des systèmes à plusieurs processeurs comportant généralement plus de huit processeurs. Cette règle est disponible uniquement sur les processeurs System i, System p, and System z. La règle subpool est identique à la règle optthruput, mais le segment de mémoire est divisé en sous-pools permettant une meilleure évolutivité pour l'affectation d'objet.

Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha

The Java Platform, Standard Edition 6 (Java SE 6) inclut la fonction de récupération de place générationnelle, ce qui permet à des pools de mémoires distincts de contenir des objets d'âges différents. Le cycle de récupération de place collecte les objets indépendamment les uns des autres en fonction de leur âge. Vous pouvez définir la taille de chaque pool de mémoire à l'aide de paramètres supplémentaires. Pour optimiser les performances, définissez la taille du pool contenant des objets à durée de vie courte, de sorte qu'ils ne perdurent pas au-delà d'un seul cycle de récupération de place. Utilisez les paramètres NewSize et MaxNewSize pour spécifier la taille du nouveau pool de génération.

-XX:NewSize=limite_inférieure 
-XX:MaxNewSize=limite_supérieure
 -XX:SurvivorRatio=nouvelle_taille_rapport 

Pratiques recommandées : Toutefois, si votre machine virtuelle utilise des segments d'une taille supérieure à 1 Go, utilisez les valeurs suivantes :

• -XX:NewSize=640m
• -XX:MaxNewSize=640m
• -XX:SurvivorRatio=16

bprac

Alternativement, vous pouvez affecter de 50% à 60% de la taille totale du segment à un nouveau pool de génération.

Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha

Vous pouvez utiliser -Xminf pour modifier le pourcentage de la taille disponible minimale du tas. Le tas croît si l'espace disponible est inférieur à la taille indiquée. En mode réinitialisation, cette argument indique le pourcentage minimal d'espace disponible dans les tas du logiciel intermédiaire et les tas transitoires. La valeur spécifiée pour cet argument est un nombre en virgule flottante, compris entre 0 et 1. La valeur par défaut est .3 (30 %).

Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha

Java HotSpot Technology dans Java SE 6 utilise une machine JVM contenant des algorithmes qui optimisent dans le temps l'exécution du bytecode. La machine JVM peut fonctionner sous deux modes : -server et -client. En général, utilisez le mode -server , générant des performances d'exécution plus efficaces sur des périodes plus longues.

Si vous utilisez le mode par défaut -client, le démarrage du serveur sera plus rapide et un encombrement de mémoire réduit sera créé. Toutefois, ce processus réduit les performances étendues. Utilisez le mode -server, qui améliorer les performances, sauf su le démarrage du serveur est plus important que les performances. Vous pouvez surveiller la taille des processus et le temps de démarrage du serveur pour vérifier la différence des performances entre les modes -client et -server.

Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha

Vous pouvez utiliser l'argument -Dcom.ibm.CORBA.RequestTimeout= intervalle_délai pour définir le délai d'expiration de réponse pour les requêtes envoyées à partir du client. Cet argument utilise l'option -D. délai_expiration est une durée exprimée en secondes. Si les temps de réponse sont trop lents sur le réseau, indiquez une valeur élevée pour éviter les délais d'attente. Si la valeur définie est trop faible, le délai d'attente autorisé pour la réception d'une réponse sur un serveur d'applications mettant en oeuvre la fonction de pondération de charge de travail risque d'être dépassé avant réception de la réponse.

Spécifiez cet argument uniquement si votre application rencontre des problèmes avec le dépassement du délai d'attente. Aucune valeur n'est recommandée pour cet argument.

L'argument -Dcom.ibm.server.allow.sigkill=true permet au processus de l'agent de noeud d'utiliser la méthode d'arrêt d'un processus lorsque la méthode d'arrêt ne se termine pas dans l'intervalle spécifié pour la commande Ping. Ce paramètre est utile si l'agent de noeud surveille un serveur d'applications et perd contact avec ce dernier.

Lorsque les règles de supervision du serveur d'applications permettent à l'agent de noeud de redémarrer le serveur d'application, car le redémarrage automatique est activé pour le serveur d'applications, l'agent de noeud exécute la méthode stop sur le processus du serveur d'applications. Au cours du traitement stop, l'agent de noeud contrôle le serveur d'applications et si ce dernier ne s'arrête pas dans le délai défini par l'intervalle Ping et que cet argument a la valeur true (valeur par défaut), l'agent de noeud exécute la méthode terminate sur le processus u serveur d'applications pour l'arrêter.

Si vous affectez à cet argument la valeur false, l'agent de noeud continue de surveiller le processus d'arrêt, mais il n'essaie pas de redémarrer le serveur d'applications.

Pour utiliser la console d'administration afin de désactiver cet argument, cliquez sur Administration du système > Agents de noeud > nom_agent_noeud > Gestion des processus & Java > Définition des processus > Machine virtuelle Java > Arguments JVM génériques.

Cet argument spécifie le nombre maximal de fois qu'une alarme indique sa trace de pile complète dans des messages d'unité d'exécution bloquée dans les journaux système.

Lorsqu'une unité d'exécution d'alarme système est active pour une durée supérieure au seuil de contrôle des unités d'exécution d'alarme, le serveur d'applications consigne un message d'unité d'exécution bloquée comportant le nom de l'unité d'exécution d'alarme, la durée pendant laquelle l'unité d'exécution d'alarme était active, et la trace de pile d'exceptions complète. La trace de pile complète est utile pour déboguer la cause du délai, mais si des messages d'unité d'exécution bloquée sont déclenchés régulièrement, la multitude de messages longs peut rendre difficile la recherche d'autres informations dans les journaux système. Associez cet argument à un entier supérieur à 0 afin de spécifier le nombre maximal de fois que chaque alarme peut indiquer sa trace de pile complète. Une fois ce seuil atteint, chaque message d'unité d'exécution bloquée suivant inclut seulement l'entrée du gestionnaire d'alarmes bloqué.

La valeur par défaut 0 indique que tous les messages d'unité d'exécution bloquée pour une alarme inclut la trace de pile complète.

Spécifiez cet argument pour ajouter un horodatage et un identificateur d'unité d'exécution à tous les messages de débogage de serveur qui sont émis dans les fichiers journaux native_stdout et native_stderr. Vous pouvez utiliser l'horodatage et l'identificateur d'unité d'exécution pour corréler les comportements des composants d'amorçage du serveur d'applications aux comportements d'autres mécanismes du serveur, qui sont indiqués dans les fichiers journaux SystemOut et SystemErr. Ce comportement est désactivé par défaut.

Lorsque le serveur est configuré avec l'argument JVM générique -Dws.ext.debug=true, il émet des messages de débogage au cours de sa séquence d'amorçage dans les fichiers native_stdout.log et native_stderr.log. Si -Dcom.ibm.websphere.native.logging.timestamp est également associé à la valeur true, le serveur émet des messages de débogage comportant un horodatage et un identificateur d'unité d'exécution, comme dans l'exemple suivant :

[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[0]=-nosplash
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[1]=-application
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher
[6/18/12 16:24:31:453 CDT] 00000000 
ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer

Cet argument s'applique uniquement à z/OS. Vous pouvez utiliser l'argument -Dcom.ibm.websphere.wlm.unusable.interval= intervalle_délai pour modifier la valeur de la propriété com.ibm.websphere.wlm.unusable.interval lorsque l'état de la pondération de charge de travail du client est régénérée trop tôt ou trop tard. Cette propriété indique le délai d'attente (en secondes) qui s'écoule entre le moment où le client de pondération de charge de travail marque un serveur comme étant non disponible et le moment où il tente à nouveau de s'y connecter. Cet argument utilise l'option -D. La valeur par défaut est 300 secondes. Si la propriété possède une valeur trop élevée, le serveur est marqué comme étant non disponible pendant une durée prolongée. Cela permet d'éviter que l'état de la fonction de pondération de charge de travail exécutée sur le client soit rafraîchi par le protocole avant expiration du délai indiqué.

Cet argument s'applique uniquement à z/OS. Vous pouvez utiliser l'argument -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= pour indiquer que la zone de stockage des mémoires tampon à octets directs doit être libérée dès que la mémoire tampon n'est plus utilisée. La seule valeur prise en charge pour cet argument est com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.

-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

Sur la plate-forme z/OS, vous devez également définir cet argument si vous spécifiez la propriété personnalisée zaioFreeInitialBuffers pour qu'un canal TCP libère les mémoires tampon de lecture initiales utilisées dans les nouvelles connexions dès que ces mémoires tampon ne sont plus nécessaires pour la connexion.

Indique si la vérification de la conformité SIP est activée dans le serveur proxy SIP. La vérification permet de déterminer si les messages SIP sont conformes à la norme SIP (Session Initiation Protocol). Si vous affectez à cette propriété la valeur true, vous activez la vérification de conformité SIP.

Eviter les incidents : Si vous utilisez un serveur proxy dans un environnement z/OS WebSphere Application Server, Network Deployment et que le serveur proxy ne fait pas partie d'un cluster, vous pouvez utiliser la propriété de serveur proxy SIP isSipComplianceEnabled pour activer ou désactiver la vérification de conformité SAP du serveur proxy SIP. Toutefois, si vous exécutez un serveur d'applications autonome et que le serveur proxy fait partie d'un cluster, vous pouvez utiliser cet argument JVM générique pour activer ou désactiver la vérification de conformité SIP.gotcha

Vous pouvez utiliser l'argument -Xshareclasses:none pour désactiver l'option de classes partagées d'un processus. L'option de classe partagée, disponible avec Java SE 6, 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.

Si vous utilisez cette option, vous devez vider le cache lorsque le processus n'est pas utilisé. Pour vider le cache, appelez l'utilitaire racine_serveur_app/bin/clearClassCache.bat/sh ou arrêtez le processus, puis relancez-le.

Eviter les incidents :

• IBM JVM for J2SE 5 n'est pas pris en charge sur Solaris, HP et IBM i.
• Les classes d'application Java EE exécutées dans un processus serveur d'applications ne sont pas ajoutées au cache de classes partagées.

gotcha

Utilisez l'argument -XXallowvmshutdown:false pour revenir à un comportement antérieur pour la machine JVM incorrecte. Java 5.0 SR10 et Java 6 SR5 résolvent les problèmes suite auxquels la machine virtuelle Java (JVM) ne s'arrête pas correctement. Si vous disposez d'une application qui dépend de l'ancien comportement, vous pouvez revenir au comportement précédent en ajoutant cet argument à la section des arguments JVM génériques.