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.

[AIX Solaris HP-UX Linux Windows] [iSeries] Pour les plateformes IBM i et réparties, cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere > nom_serveur. Ensuite, dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.

[z/OS] Pour la plateforme z/OS, suivez l'un des chemins d'accès suivants.
Serveur d'applications Cliquez sur Serveurs>Types de serveur>Serveurs d'applications WebSphere> nom_serveur. Ensuite, dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Contrôle > Machine virtuelle Java.
Gestionnaire de déploiement Cliquez sur Administration système > Gestionnaire de déploiement. Ensuite, dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Contrôle > Machine virtuelle Java.
Agent de noeud Cliquez sur Administration du système > Agent de noeud > agent_de_noeud. Ensuite, dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
[AIX Solaris HP-UX Linux Windows] [iSeries] Pour les plateformes IBM i et réparties, suivez l'un des chemins d'accès suivants :
Serveur d'applications Serveurs > Types de serveurs > Serveurs d'applications WebSphere > nom_serveur. Ensuite, dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
Gestionnaire de déploiement Administration système > Gestionnaire de déploiement. Ensuite, dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
Agent de noeud Administration du système > Agent de noeud > agent_noeud. Ensuite, dans la section Infrastructure du serveur, cliquez sur Gestion des processus et Java > Définition des processus > Machine virtuelle Java.
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.

Les seuls chemins de classe devant être ajoutés dans cette zone sont ceux qui spécifient l'emplacement des éléments suivants :
  • 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.
Des erreurs de traitement peuvent survenir si vous ajoutez des chemins de classe à cette zone spécifiant l'emplacement des éléments suivants :
  • 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.
Type de données 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 JVM, pour les séparer.

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.

Les seuls chemins de classe devant être ajoutés dans cette zone sont ceux qui spécifient l'emplacement des éléments suivants :
  • 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.
Des erreurs de traitement peuvent survenir si vous ajoutez des chemins de classe à cette zone spécifiant l'emplacement des éléments suivants :
  • 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é.

[AIX Solaris HP-UX Linux Windows] Si le chargement des classes en mode prolixe est activé, le débogage est envoyé à l'un des journaux de processus natif.

Type de données Booléen
Valeur 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.

[AIX Solaris HP-UX Linux Windows] Si la récupération de place prolixe est activée, le débogage est envoyé à l'un des journaux de processus natif.

Type de données Bbooléen
Valeur 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 indiquer la manière dont le processus de récupération de place Java fonctionne.

Vous pouvez vérifier le rapport verboseGC pour déterminer :
  • 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.

[z/OS] 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 de mémoire 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 le mode prolixe de débogage pour les appels de méthodes de l'interface native Java (JNI) est utilisé. Par défaut, l'activité JNDI (Java Native Interface) en mode prolixe n'est pas activée.

Type de données Booléen
Valeur 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.

[z/OS] Pour z/OS, la valeur par défaut de la taille initiale du segment de la région de contrôle est de 48 Mo et celle par défaut de la région servante est de 128 Mo. Ces valeurs par défaut s'appliquent à la fois aux configurations 31 bits et 64 bits.

[AIX Solaris HP-UX Linux Windows] [iSeries] Pour les plateformes IBM i et les plateformes réparties, la valeur par défaut de la taille initiale du segment est de 50 Mo.

Meilleure pratique : Ces valeurs par défaut devraient convenir pour la plupart des applications.bprac
[iSeries] Eviter les incidents : Pour IBM i, la taille initiale du segment doit toujours être inférieure à la taille maximale du segment. Ne définissez jamais la même valeur pour la taille initiale et la taille maximale du segment.gotcha

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

En général, 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 de segment maximale par défaut est de 256 Mo. Cette valeur par défaut est valable pour les configurations 31 bits et 64 bits.

L'augmentation du paramètre taille maximale du segment 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 pourcent.

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.

[z/OS] 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.

[iSeries] Pour IBM i, quand cette propriété est paramétrée à 0 (zéro), le programme de récupération de place s'exécute uniquement quand le seuil du programme de récupération de place est atteint. Lorsqu'une valeur différente de 0 est définie, le récupérateur de place s'exécute à chaque fois que la taille du tas atteint la taille maximale spécifiée. Cependant, contrairement à un récupérateur de place normal, si la taille maximale est atteinte, toutes les unités d'exécution d'application doivent attendre que le processus de récupération de place soit terminé avant de pouvoir continuer leur exécution. Cette situation peut entraîner des temps de pause indésirables. Par conséquent, vous devez utiliser la taille maximale du tas comme filet de sécurité afin de gérer les périodes de croissance de tas inattendues et de vous assurer que la taille du tas ne deviendra pas supérieure à la mémoire disponible. En règle générale, la taille maximale du tas spécifiée ne doit jamais être atteinte.

Meilleure pratique : Ces valeurs par défaut devraient convenir pour la plupart des applications. Activez la propriété Processus de récupération de place en mode prolixe si vous estimez que la récupération de place se produit trop fréquemment. Si c'est le cas, augmentez la taille maximale du tas JVM.bprac
Exécuter HProf [AIX Solaris HP-UX Linux Windows] [iSeries]

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.

Type de données Booléen
Valeur par défaut false
Arguments HProf [AIX Solaris HP-UX Linux Windows] [iSeries]

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.

Type de données Booléen
Valeur 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.

Si vous activez le débogage sur plusieurs serveurs d'applications, 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.

Type de données Chaîne
Unité Java command-line arguments
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.

Vous pouvez entrer les arguments de ligne de commande suivants (facultatifs) dans la zone Arguments JVM génériques. Si vous entrez plusieurs arguments, laissez un espace entre chacun d'eux.
Eviter les incidents : Si l'argument signale qu'il concerne uniquement IBM Developer Kit, vous ne pouvez pas utiliser cet argument avec la machine virtuelle Java d'un autre fournisseur, comme Microsoft ou Hewlett-Packard, par exemple.gotcha
  • [z/OS] [AIX Solaris HP-UX Linux Windows] hotRestartSync:

    Vous pouvez utiliser hotRestartSync pour activer la fonction de synchronisation en cas de 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.CORBA.RequestTimeout=intervalle-délai

    Cet argument s'applique uniquement pour z/OS. 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.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 correspond à 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é.

  • [z/OS] -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

    [z/OS] Sur la plateforme z/OS, vous devez également spécifier cet argument si vous spécifiez 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.

  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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 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.

    [iSeries] Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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.
    Meilleure pratique : -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
    [iSeries] Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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 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.
    • [iSeries] IBM i ne prend pas en charge cet argument.
    gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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 appartenant à ces classes restent utilisées même lorsque les classes ne sont pas appelées.

    Eviter les incidents : L'impact sur les performances de la collecte de récupération de place est généralement minime et la désactivation de cette collecte sur un système Java EE (Java Platform, Enterprise Edition), avec une utilisation intensive des chargeurs de classes d'application, peut provoquer une fuite de mémoire des données des classes et amener la machine JVM à générer une exception de mémoire insuffisante.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.

    [iSeries] 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
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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. Par exemple, si 3 processeurs s'exécutent sur votre machine, entrez -Xgcthreads 3. Sur un noeud hébergeant n processeurs, le nombre par défaut d'unités d'exécution est n.

    Meilleure pratique : Utilisez la fonction de récupération de place parallèle si votre machine est équipée de plusieurs processeurs.bprac
    [iSeries] Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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.

    [iSeries] Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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.

    Définissez cet argument sur 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. Il s'agit du paramètre par défaut recommandé.

    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 à 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 systèmes IBM System i, System p et 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.

    [iSeries] Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -XX

    JavaSE 6 (Java Platform, Standard Edition 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 dont l'ancienneté est variable. 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.

    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 pour personnaliser les paramètres du pool de génération pour une meilleure adaptation à votre environnement.
    -XX:NewSize=limite_inférieure 
    -XX:MaxNewSize=limite_supérieure
     -XX:SurvivorRatio=nouvelle_taille_rapport 
    Les valeurs par défaut sont les suivantes :
    • NewSize=2m
    • MaxNewSize=32m
    • SurvivorRatio=32
    Meilleure pratique : 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.

    [iSeries] Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -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 %).

    [iSeries] Eviter les incidents : IBM i ne prend pas en charge cet argument.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xshareclasses:none

    Vous pouvez utiliser l'argument -Xshareclasses:none pour désactiver l'option de classes partagées d'un processus. Cette option, disponible avec Java SE 6, vous 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 :
    • [Solaris] [iSeries] [HP-UX] La machine virtuelle Java IBM pour J2SE 5 n'est pas prise en charge sur Solaris, HP et IBM i.
    • Les classes d'application J2EE s'exécutant dans un processus de serveur d'applications ne sont pas ajoutées au cache des classes partagées.
    gotcha
Type de données 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.

Type de données 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.

Type de données Booléen
Valeur 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 serveur comme paramètres JVM du système d'exploitation.

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.




Les liens marqués (en ligne) requièrent un accès à Internet.

Tâches associées
Référence associée
Collection de propriétés personnalisées
[AIX Solaris HP-UX Linux Windows]


Nom du fichier : urun_rconfproc_jvm.html