Paramètres de la machine virtuelle Java
Cette page permet d'afficher et de modifier les paramètres de configuration de la machine virtuelle Java™ (JVM) d'un processus pour un serveur d'applications.
Pour afficher cette page de la console d'administration, connectez-vous à la console d'administration et accédez au panneau de la machine virtuelle Java.
![[z/OS]](../images/ngzos.gif)
Information | valeur |
---|---|
Serveur d'applications | Cliquez sur | . Ensuite, dans la section Infrastructure du serveur, cliquez sur .
Gestionnaire de déploiement | Cliquez sur | . Ensuite, dans la section Infrastructure du serveur, cliquez sur .
Agent de noeud | Cliquez sur | . Ensuite, dans la section Infrastructure du serveur, cliquez sur .
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Information | valeur |
---|---|
Serveur d'applications | . Ensuite, dans la section Infrastructure du serveur, cliquez sur . |
Gestionnaire de déploiement | . Ensuite, dans la section Infrastructure du serveur, cliquez sur . |
Agent de noeud | . Ensuite, dans la section Infrastructure du serveur, cliquez sur . |
Chemin d'accès aux classes
Indique le chemin d'accès aux classes standard dans lequel le code de la machine virtuelle Java recherche des classes.
Si vous devez ajouter un chemin de classe dans cette zone, entrez chaque entrée de chemin de classe dans des lignes de table distinctes. Il n'est pas nécessaire d'ajouter une virgule ou un point virgule à la fin de chaque entrée.
- L'outil de contrôle ou d'inspection de votre système.
- Les fichiers JAR d'un produit s'exécutant par-dessus ce produit.
- Les correctifs ou modules de correction de diagnostic JVM.
- Les fichiers JAR des fournisseurs de ressources, comme par exemple DB2. Les chemins d'accès de ces fichiers JAR doivent être ajoutés aux chemins de classe du fournisseur adéquat.
- Un fichier JAR utilisateur qui est utilisé par une ou plusieurs applications s'exécutant sur le produit. Le chemin de ce type de fichier JAR doit être spécifié dans chaque application nécessitant ce fichier JAR ou dans les bibliothèques partagées associées au serveur.
- Un fichier JAR d'extension. Si vous devez ajouter un fichier JAR d'extension à votre système, vous devez utiliser la propriété personnalisée JVM ws.ext.dirs pour spécifier le chemin absolu de ce fichier JAR. Vous pouvez également placer le fichier JAR dans le répertoire WAS_HOME/lib/ext/, mais l'utilisation de la propriété personnalisée JVM ws.ext.dirs est la méthode recommandée pour spécifier le chemin vers un fichier d'extension JAR.
Information | valeur |
---|---|
Type de données | String (chaîne) |
Chemin d'accès aux classes amorce
Indique les ressources et les classes d'amorçage pour le code JVM. Cette option est disponible uniquement pour les instructions JVM qui prennent en charge les ressources et les classes d'amorçage.
Si vous devez ajouter un chemin de classe dans cette zone, saisissez chaque entrée de chemin de classe dans une ligne de table. Il n'est pas nécessaire d'ajouter une virgule ou un point virgule à la fin de chaque entrée.
Si vous devez ajouter plusieurs chemins de classe à cette zone, vous pouvez utiliser les deux points (:) ou le point virgule (;), selon le système d'exploitation sur lequel réside le noeud, pour les séparer.
- L'outil de contrôle ou d'inspection de votre système.
- Les fichiers JAR d'un produit s'exécutant par-dessus ce produit.
- Les correctifs ou modules de correction de diagnostic JVM.
- Les fichiers JAR des fournisseurs de ressources, comme par exemple DB2. Les chemins d'accès de ces fichiers JAR doivent être ajoutés aux chemins de classe du fournisseur adéquat.
- Un fichier JAR utilisateur qui est utilisé par une ou plusieurs applications s'exécutant sur le produit. Le chemin de ce type de fichier JAR doit être spécifié dans chaque application nécessitant ce fichier JAR ou dans les bibliothèques partagées associées au serveur.
- Un fichier JAR d'extension. Si vous devez ajouter un fichier JAR d'extension à votre système, vous devez utiliser la propriété personnalisée JVM ws.ext.dirs pour spécifier le chemin absolu de ce fichier JAR. Vous pouvez également placer le fichier JAR dans le répertoire WAS_HOME/lib/ext/, mais l'utilisation de la propriété personnalisée JVM ws.ext.dirs est la méthode recommandée pour spécifier le chemin vers un fichier d'extension JAR.
Chargement des classes en mode prolixe
Indique si le mode prolixe de débogage est utilisé pour le chargement des classes. Par défaut, le chargement des classes en mode prolixe n'est pas activé.
Si le chargement des classes en mode prolixe est activé, le débogage est envoyé à l'un des journaux de processus natif.
Information | valeur |
---|---|
Type de données | Booléenne |
Valeut par défaut | false |
Processus de récupération de place en mode prolixe
Indique si le mode prolixe de débogage pour le processus de récupération de place Java est utilisé. Par défaut, la récupération de place en mode prolixe n'est pas activée.
Si la récupération de place prolixe est activée, le débogage est envoyé à l'un des journaux de processus natif.
Information | valeur |
---|---|
Type de données | Booléenne |
Valeut par défaut | false |
Lorsque cette option est activée, un rapport est écrit dans le flux de sortie à chaque exécution de la récupération de place. Ce rapport doit vous donner un aperçu du processus de récupération de place Java.
- Le temps que la machine virtuelle Java passe à effectuer la récupération de place.Dans l'idéal, elle devrait passer moins de 5 % de son temps de traitement à effectuer de la récupération de place. Pour connaître le pourcentage du temps passé en récupération de place, divisez le temps écoulé pour terminer la récupération par le temps écoulé depuis le dernier accès fichier et multipliez le résultat par 100. Par exemple :
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.
- Si la taille du tas alloué augmente avec chaque occurrence de récupération de place.
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.
Sur la plateforme z/OS, vous pouvez également exécuter la commande de console MVS, modify display, jvmheap, pour afficher les informations relatives au segment JVM. En outre, vous pouvez vérifier l'activité du serveur et les enregistrements SMF d'intervalles. La taille du segment JVM est aussi disponible dans l'interface PMI et
peut être contrôlée au moyen de
Tivoli
Performance Viewer.
JNI en mode prolixe
Indique si la sortie prolixe de débogage pour l'appel de méthode natif est utilisée. Par défaut, l'activité JNDI (Java Native Interface) en mode prolixe n'est pas activée.
Information | valeur |
---|---|
Type de données | Booléenne |
Valeut par défaut | false |
Taille initiale du tas
Indique la taille initiale du segment (tas) Java attribué au code de la JVM. Si cette zone est vide, la valeur par défaut est utilisée.
Pour z/OS,
la taille de segment de mémoire initial par défaut est de 256 Mo pour le contrôleur et de 512 Mo pour le serviteur.
Pour IBM® i et les plateformes réparties, la valeur par défaut de la taille initiale du
segment est 50 Mo.


L'augmentation de ce paramètre peut améliorer les performances au démarrage. Le nombre d'occurrences de récupération de place diminue et les performances augmentent de 10 %.
L'augmentation de la taille du segment Java améliore le débit, jusqu'à ce que le segment soit trop grand pour résider dans la mémoire physique. Si la taille du segment est supérieure à la mémoire physique disponible et qu'une pagination se produit, la performance diminue de manière significative.
Taille maximale du tas
Indique la taille maximale du segment Java attribué au code de la JVM. Si cette zone est vide, la valeur par défaut est utilisée.
La taille maximale de segment de mémoire par défaut correspond à 25 % du volume total de mémoire système jusqu'à 4 Go, ou à la valeur par défaut de la machine virtuelle Java, chaque fois que la taille mémoire est inaccessible.
L'augmentation du paramètre de taille maximale de segment de mémoire peut améliorer les performances au démarrage. Lorsque vous augmentez la taille du segment, vous réduisez le nombre d'occurrences de récupération de place et augmentez les performances de 10 pour cent.
En général, l'augmentation de ce paramètre améliore le débit, jusqu'à ce que le segment soit trop grand pour résider dans la mémoire physique. Si la taille du segment est supérieure à la mémoire physique disponible et qu'une pagination se produit, la performance diminue de manière significative. Par conséquent, il est important que la valeur spécifiée pour cette propriété permette à la mémoire physique de contenir le segment.
Pour z/OS, la taille de segment de mémoire maximal par défaut est de 512 Mo pour le contrôleur et de 1024 Mo pour le serviteur. Pour éviter la pagination, attribuez à cette propriété une valeur minimale de 256 Mo de mémoire physique pour chaque processeur et de 512 Mo de mémoire physique pour chaque serveur d'applications. Si le taux d'utilisation des processeurs est bas en raison de la pagination, dans la mesure du possible,
augmentez la capacité de mémoire disponible plutôt que la taille maximale du tas Java. L'augmentation de la taille maximale du tas peut réduire les performances au lieu de les améliorer.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Exécuter HProf
Détermine l'utilisation du support du profileur HProf. Pour utiliser un autre profileur, spécifiez les paramètres du profileur personnalisé via le paramètre Arguments HProf. Par défaut, le support du profileur HProf n'est pas activé.
Si la valeur true est attribuée à la propriété Exécuter HProf, vous devez spécifier les arguments du profileur de ligne de commande comme valeurs de la propriété Arguments HProf.
Information | valeur |
---|---|
Type de données | Booléenne |
Valeut par défaut | false |
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Arguments HProf
Indique les arguments de profileur de ligne de commande à transmettre au code JVM qui lance le processus du serveur d'applications. Vous pouvez spécifier les arguments lorsque le support du profileur HProf est activé.
Les arguments HProf sont requis uniquement si la valeur de la propriété Exécuter HProf est true.
Mode de débogage
Indique si la JVM doit être exécutée en mode débogage. Par défaut, la prise en charge du mode de débogage n'est pas activée.
Si la valeur true est attribuée à la propriété Mode de débogage, vous devez spécifier les arguments du débogage de ligne de commande comme valeurs de la propriété Arguments de débogage.
Information | valeur |
---|---|
Type de données | Booléenne |
Valeut par défaut | false |
Arguments de débogage
Indique les arguments de débogage de ligne de commande à transmettre au code JVM qui lance le processus du serveur d'applications. Vous pouvez spécifier les arguments lorsque la propriété Mode de débogage est définie sur true.
Si vous activez le débogage sur plusieurs serveurs d'applications résidant sur le même noeud, vérifiez que la même valeur n'est pas spécifiée pour l'argument address. L'argument address définit le port utilisé pour le débogage. Si deux serveurs, pour lesquels le débogage est activé, sont configurés pour utiliser le même port de débogage, leur démarrage peut échouer. Par exemple, les deux serveurs peuvent être configurés avec l'argument de débogage address=7777, qui est la valeur par défaut de l'argument address de débogage.
Information | valeur |
---|---|
Type de données | String (chaîne) |
Unité | Arguments de ligne de commande Java |
Arguments JVM génériques
Indique les arguments de ligne de commande à transmettre au code de la machine virtuelle Java qui lance le processus de serveur d'applications.

-DhotRestartSync :
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.
- -Dcom.ibm.crypto.provider.doAESInHardware:
Affectez à cette option la valeur true pour activer la fonction AES (Advanced Encryption Standard) fournie avec le kit de développement de logiciels IBM SDK et 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.
-Xquickstart
Vous pouvez utiliser -Xquickstart pour la compilation initiale à un niveau d'optimisation inférieur que le mode par défaut. Ensuite, suivant certains résultats d'échantillonnage, vous pouvez effectuer une recompilation au niveau de la compilation initiale du mode par défaut.Pratiques recommandées: -Xquickstart est utile pour les applications dans lesquelles un débit modéré à court terme est plus important qu'un débit à long terme. Dans certains scénarios de débogage, routines de test et outils à exécution courte, vous pouvez optimiser la durée de démarrage de 15 à 20 %.bprac
Eviter les incidents: IBM i ne prend pas en charge cet argument.gotcha
-Xverify:none
Vous pouvez utiliser -Xverify:none pour sauter l'étape de vérification de classe au cours du chargement de classes. L'élément -Xverify:none permet de désactiver la vérification de la classe Java, ce qui peut entraîner une réduction de 10 à 15 % du 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 é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 virtuelle Java ou si cette dernière 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 virtuelle Java consiste à retirer cet argument.
Cet argument n'est pas pris en charge pour l'IBM i.
-Xnoclassgc
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 qui appartiennent à 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 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.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: Cet argument n'est pas pris en charge pour IBM i. Vous devez utiliser l'argument -noclassgc pour désactiver la collecte des classes pour libération mémoire sur cette plateforme.gotcha
-Xgcthreads
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 spécification de -Xgcthreads avec cinq processeurs.
gotchaPratiques 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
-Xnocompactgc
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. Evitez la compression du segment si vous utilisez IBM Developer Kit. 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
-Xgcpolicy
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 balanced si vous souhaitez utiliser le marquage, le balayage, le compactage et la récupération de place de style générationnel. La phase de marquage simultanée est désactivée ; la technologie de récupération de place simultanée est utilisée, mais pas de la manière dont le marquage simultané est implémenté pour les autres règles. La règle équilibrée utilise une disposition basée sur la région pour le segment de mémoire Java. Ces régions sont gérées individuellement afin de réduire le délai d'interruption sur les segments de mémoire de grande taille et d'augmenter l'efficacité de la récupération de place. La règle tente d'éviter les récupérations globales en faisant correspondre les taux d'allocation d'objet et de survie. Si vous rencontrez des problèmes avec les délais de pause d'application provoqués par les récupérations de place globales, notamment la compression, cette règle peut améliorer les performances de l'application. Si vous utilisez des systèmes de grande taille dotés de caractériques NUMA (Non-Uniform Memory Architecture) (plateformes x86 et POWER uniquement), la règle équilibrée peut améliorer davantage le débit de l'application.
Eviter les incidents: Cet argument n'est pas pris en charge pour IBM i.gotcha
-XX
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 que les objets du pool 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 générationnel.
Les objets qui survivent au premier cycle de récupération de place sont transmis à un autre pool. Utilisez le paramètre SurvivorRatio pour spécifier la taille du pool des survivants. SurvivorRatio. Vous pouvez utiliser les statistiques d'objet que Tivoli Performance Viewer collecte ou inclure l'argument verbose:gc dans votre paramètre de configuration afin de surveiller les statistiques de récupération de place. Si la récupération de place devient un goulot d'étranglement, spécifiez les arguments suivants afin de personnaliser les paramètres du pool générationnel pour une meilleure adaptation à votre environnement.-XX:NewSize=lower_bound -XX:MaxNewSize=upper_bound -XX:SurvivorRatio=new_ratio_size
Les valeurs par défaut sont les suivantes :- NewSize=2m
- MaxNewSize=32m
- SurvivorRatio=32
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
Vous pouvez aussi affecter de 50% à 60% de la taille totale du segment à un nouveau pool générationnel.
Eviter les incidents: IBM i ne prend pas en charge cet argument.gotcha
-Xminf
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: Cet argument n'est pas pris en charge pour IBM i.gotcha
-server | -client
La technologie Java HotSpot de Java SE 6 utilise une machine virtuelle Java adaptative contenant des algorithmes qui, au fil du temps, optimisent l'exécution du code intermédiaire. 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 si 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
- -Dcom.ibm.CORBA.RequestTimeout=intervalle-délai
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.
- -Dcom.ibm.server.allow.sigkill=true
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 pour 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 et Java > Définition des processus > Machine virtuelle Java > Arguments JVM génériques.
- -Dcom.ibm.websphere.alarmthreadmonitor.hung_alarm_mute=
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.
Remarque : Cette propriété spécifie un seuil pour chaque classe de gestionnaire d'alarmes, et non pour le nombre total de messages ni pour chaque instance de gestionnaire d'alarmes. - -Dcom.ibm.websphere.native.logging.timestamp=true
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
Remarque : Spécifiez -Dws.ext.debug=true uniquement sous le contrôle du support IBM. - -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true
Spécifiez -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true lorsque les référentiels DB/LA du gestionnaire de membre virtuel sont partagés par plusieurs installations. Cette propriété n'est pas destinée à être utilisée dans des environnements de cluster. La définition de cette propriété permet au gestionnaire VMM de synchroniser les appels provenant d'installations WebSphere Application Server qui partagent des référentiels.
-Dcom.ibm.websphere.wlm.unusable.interval=intervalle
Cet argument s'applique uniquement pour 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é.
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=
Cet argument s'applique uniquement pour 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.
Les mémoires tampon à octets directs créés par la machine virtuelle Java pour gérer les données de demande, sont attribuées dans le segment Language Environment (LE) et non dans le segment JVM. En général, même si les mémoires tampon à octets directs ne sont plus utilisées, la machine virtuelle Java ne libère pas la zone de stockage LE natif tant que la procédure de récupération de place suivante n'est pas exécutée. Si le serveur doit traiter de grosses demandes, la mémoire LE peut arriver à épuisement avant que la JVM n'exécute son prochain cycle de récupération de place, provoquant alors la fin anormale (abend) du serveur. La configuration de la JVM à l'aide de l'argument suivant empêche la survenue de ces procédures d'abandon.-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
Sur la plateforme z/OS, vous devez également spécifier cet argument si vous indiquez la propriété personnalisée zaioFreeInitialBuffers pour un canal TCP de manière à ce qu'il libère les mémoires tampon de lecture initiales utilisées sur les nouvelles connexions dès que celles-ci ne sont plus nécessaires à la connexion.
-DisSipComplianceEnabled=true|false
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 exécutez 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é personnalisée de serveur proxy SIP isSipComplianceEnabled pour activer ou désactiver la vérification de conformité SIP de ce 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
-Xshareclasses:none
Vous pouvez utiliser l'argument -Xshareclasses:none pour désactiver l'option de classes partagées d'un processus. 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 la mémoire cache, appelez l'utilitaire <app_server_root>/bin/clearClassCache.bat 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.Eviter les incidents:
- Les classes d'application Java EE qui s'exécutent dans un processus de serveur d'applications ne sont pas ajoutées au cache des classes partagées.
- -XXallowvmshutdown:false
Utilisez l'argument -XXallowvmshutdown:false pour revenir à un comportement antérieur pour la machine JVM incorrecte. 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.
Information | valeur |
---|---|
Type de données | String (chaîne) |
Unité | Arguments de ligne de commande Java |
Nom du fichier JAR du programme exécutable
Indique le nom du chemin complet d'un fichier JAR exécutable utilisé par le code de la JVM.
Information | valeur |
---|---|
Type de données | String (chaîne) |
Unité | Nom de chemin d'accès |
Désactivation du compilateur JIT
Indique s'il est nécessaire de désactiver l'option du compilateur JIT (just-in-time) du code de la JVM.
Si vous désactivez le compilateur JIT, le débit diminue sensiblement. Pour obtenir de meilleures performances, évitez de désactiver le compilateur JIT.
Information | valeur |
---|---|
Type de données | Booléenne |
Valeut par défaut | false (JIT activé |
Recommandé | JIT activé |
Nom du système d'exploitation
Spécifie les paramètres de la JVM spécifiques à un système d'exploitation donné.
Lorsque le processus démarre, il utilise les paramètres JVM spécifiés pour le noeud comme paramètres JVM du système d'exploitation.