Jean FRANCOIS blog [Weblogic / Java EE / SOA]: JVM (principes de paramétrage)

mercredi 1 avril 2009

JVM (principes de paramétrage)

02:29 |

Publié par Jean FRANCOIS |

Modifier l'article

Cet article propose de dégager de façon globale des règles de paramétrage de JVM pour un environnement de production. Elles constituent un point d’entré pour obtenir une plate-forme stable, mais pas un tuning fin. Pour cela, il faudra composer avec les spécificités de chaque application et de leurs consommations mémoire, ainsi que les optimisations offertes sur chaque JVM fonction de l’éditeur.

La JVM est un composant mangeure dans l’architecture Weblogic car c’est elle qui permet d’accéder à la ressource machine via l’O.S ou une infrastructure de virtualisation. Si ce composant fonctionne mal, c’est la totalité de la plate-forme WLS qui est impactée.

Elle permet également de compartimenter ces ressources pour s’assurer d’un espace disponible mémoire dédié et une répartition des traitements simultanés sur la CPU (la virtualisation pouvant compartimenter la partie CPU).

L’impacte du paramétrage de JVM peut être influant sur les aspects suivants :

ü La gestion mémoire.

ü Le type de GC déclenché, leurs longueurs et l’impacte sur l’indisponibilité de la JVM.

ü L’optimisation du code généré.

Il faut s’assurer en premiers lieux du bon fonctionnement des ressources en dessous de la JVM, c’est à dire :

ü La machine s’assurer du bon choix de la CPU et du bon fonctionnement des périphériques.

ü Le réseau Vérifier les composants constitutifs et des temps d’accès.

ü L’O.S Valider l’optimisation et le paramétrage.

Chaque éditeur à sa propre version de noyau, mais implémente la même version de JDK. Le fonctionnement interne et l’optimisation peut donc varier d’une JVM à l’autre du fait de ces internes spécifique (en version et éditeur différent).

SYSTEM

Vérifier le bon fonctionnement réseau et machine, ainsi que les paramétrages OS afin d’obtenir le meilleur temps de réponse.

Valider les PATCH O.S fonction de l’éditeur en corrodante avec la version de JVM que vous voulez utiliser.

De préférence, prendre la dernière version de la JVM en accord avec les préconisations support Oracle afin d’embarquer les derniers correctifs et se prémunir de défaillance du noyau de la JVM.

J.I.T

La JVM compile le byte code en code compilé afin d’optimiser le temps d’exécution et se rapprocher le plus prés possible du code machine cible. Cette phase se fait au fur et à mesure des requêtage selon certaines stratégies. Cette procédure n’est pas persistance et doit être rejouée à chaque redémarrage de la JVM.

La plupart du temps on distingue deux types de compilation fonction de l’environnement utilisé.

ü Développement Il existe une compilation dédiée aux environnements de développement avec une phase d’optimisation rapide, mais peu performante. Ce type d’environnement impose des modifications relativement fréquentes du code java, ainsi qu’un redémarrage fréquent de la JVM, d’ou des contraintes particulières.

ü ¨Production Pour un environnement de production, le code est théoriquement modifié et déployé peu souvent avec des redémarrages de JVM à fréquence espacée. L’optimisation est donc plus longue, mais plus performante afin d’obtenir les meilleurs temps de réponse.

Le mode par défaut et le type de paramétrage peuvent varier d’une JVM à l’autre, et les phases d’optimisation sont spécifiques par rapport au noyau de l’éditeur et de la version.

Dans le cas de crash de JVM sans génération de log (arrêt brutal), le problème se trouve en général dans le code généré par la JVM qui fait crasher le processus. Trois solutions sont possibles :

ü Changer de version de JVM afin de corriger le bug.

ü Changer le type de JIT.

ü Désactiver complètement le JIT ou juste sur la classe incriminée (voir le dump généré).

MEMOIRE

· La JVM a la spécificité d’attribuer une zone mémoire physique dédiée à l’application (HeapSize). Cela permet de se prémunir contre les dépassements système des processus et d’allouer tout de suite un ensemble de blocs prêts à l’utilisation (gain de temps sur les allocations).

Cependant, le processus JAVA à également besoin en interne de mémoire pour fonctionner, et certaines zones issues de la partie applicative peuvent être alloué en dehors de la HeapSize. La taille de la HeapSize ne représente donc pas la taille réelle occupée par le processus.

En interne de la HeapSize le plus souvent deux zones sont créées. Une pour les nouveaux objets (nursery), l’autre pour les objets d’une durée de vie plus longue.

Globalement ou pourra appliquer le ratio suivant :

ü Prendre 70% de la mémoire physique pour les instances JAVA et 30% pour le système.

ü Pour l’instance, prévoir une HeapSize suffisante en sachant que le processus prend 30% en plus.

ü Répartir la HeapSize avec 30% de tenured et 70% de nursery (ne pas dépasser 70% sur la tenured)

HeapSize = Tenured 30% + Nursery 70%

Proc Java = HeapSize + 30%

Machine = System 30% + SUM (Proc Java ) 70%

· Concernant la mémoire globale, on peut distinguer la mémoire totale associé à la HeapSize, le footprint Œ qui correspond aux données résiduelles et la mémoire libre pour desservir la charge de création d’objet.