Pimp my JVM

Au cours de mes missions, je suis à chaque fois éberlué par l’absence de soin apporté au paramétrage des JVM!

En général, on se contente de s’assurer que les applications démarrent et tournent quelques temps sans crasher, en gros:

  1. “java.lang.OutOfMemoryError: Java heap space” –> on bricole Xmx,
  2. “java.lang.OutOfMemoryError: PermGen space” –> on bricole MaxPermSize,
  3. on s’arrête là, avec le sentiment du devoir accompli…

Et bien non, le travail ne s’arrête pas là, une JVM, ça se tune!

Pourquoi, si les utilisateurs sont satisfaits des perfs, me diriez vous? Pourquoi se passer d’un quick win pareil, répondrais-je!

  • Bien souvent, les utilisateurs ont baissé les bras et ont simplement accepté l’idée qu’il était normal que les applis de gestion rament et s’affichent en 3 secondes
  • On pourrait très bien se passer du 2ème serveur que les Opérations ont en tête d’acheter pour tenir la charge…

Une JVM est une plateforme générique dont les utilisations peuvent être diverses : serveur d’application JEE, traitement batch ou daemon, client lourd avec interface graphique, etc.
Les JVM modernes ont des paramétrages par défaut relativement passe-partout pour s’adapter avec plus ou moins de bonheur à ces use cases très différents. Elles intuitent même dans une certaine mesure le comportement attendu en fonction des caractéristiques de la machine.
Mais cela ne suffit pas toujours. De nombreuses améliorations sont disponibles pendant des années avant d’être généralisées et de devenir des paramétrages par défaut. Il est important de tester différents paramétrages et de les confronter à la réalité, notamment au travers de tests de charges. Il s’agit d’un processus itératif : on tente un paramétrage, on benche et on boucle juqu’à ce que le résultat soit jugé satisfaisant.

A titre d’exemple, chez un de nos client, l’ensemble des applications de tout le parc applicatif tournant sous WAS ont vu leurs performances doubler le jour où nous avons poussé un autre paramétrage du Garbage Collector. Le paramétrage par défaut sur la JVM IBM n’est simplement pas adapté à… des applications JEE! Oo Et tout ça en rajoutant quelques caractères dans la commande de démarrage…

Pourtant, tuner une JVM n’est pas un art obscur réservé à quelques gourous. Il suffit souvent de lire la doc

Le net regorge d’informations sur le tuning de JVM. Codecentric publie en ce moment une série d’articles sur Hotspot qui constitue un bon point d’entrée.

VN:R_U [1.9.22_1171]
Rating: +1 (from 1 vote)
Share
Ce contenu a été publié dans Trucs & astuces, avec comme mot(s)-clef(s) , . Vous pouvez le mettre en favoris avec ce permalien.

4 réponses à Pimp my JVM

  1. Question qui peut paraitre bête : on est d’accords que le tuning de la JVM dépend de l’application qu’on y lance. Est-ce qu’il peut aussi dépendre des caractéristiques physiques de la machine ? Ca parait évident pour la quantité de mémoire allouée, mais est-ce qu’il y a possibilité de mieux tirer parti d’un quad core par exemple, en plus de faire une application multithreadée ? Je pense notamment à différents types d’ordonnanceurs plus ou moins optimisés selon le nombre de threads lancés.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  2. J’ai du mal à comprendre la question, dsl…

    En ce qui concerne les cores/procs, la JVM est censée se débrouiller pour en tirer parti des différents processeurs disponibles.
    En ce qui concerne les Threads, tu peux définir leur priorité, mais sous HotSpot, tu peux jouer sur le paramètre -XX:+UseThreadPriorities pour utiliser les priorité natives.
    En pratique, on joue plutôt sur la priorité des “tâches” plutôt que sur celle des threads, genre PriorityBlockingQueue.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. Je vais reformuler la question avec un exemple. Qu’est-ce qui se passe si tu as 5 threads avec une priorité égale, mais 2 qui font beaucoup plus de choses que les 3 autres ?
    Est-ce que la JVM va favoriser les gros consommateurs de CPU pour qu’ils finissent plus vite ?
    Est-ce que ça va tourner avec une équité dans le temps d’exécution ?
    Est-ce que c’est configurable en changeant la politique de scheduling ?

    Le multi-core n’est qu’un exemple, il y a peut-être d’autres optimisations matérielles auxquelles je n’ai pas pensé.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  4. Non, la JVM ne va pas favoriser les gros consommateurs. Elle ne doit de toute façon pas modifier la priorité des Threads.

    Il faut distinguer 2 choses : le scheduler de Threads de la JVM, et la manière dont l’OS choisit de leur donner du CPU.

    Le rôle du scheduler est de déterminer quel Thread passer à l’OS. Il travaille par priorité, et de préemptive (un nouveau Thread va prendre le pas sur les Threads existants de priorité plus faible). A priorité égale, il va faire du FIFO.

    Ensuite, c’est l’OS qui se débrouille et qui décide. On note donc au passage que le comportement des Threads est complètement dépendant de l’OS (méthode yield par exemple).

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)

Laisser un commentaire