blog.bressure.net

L’histoire commence par la mise à jour de Jira 4 vers Jira 6. Ce dernier étant plus gourmand en mémoire, il utilise une JVM configurée pour demander à l’OS quelques 1,1 Go de mémoire (PermGenSpace et Xmx). Ce qui n’est vraiment pas un pré-requis exceptionnel. Mon PC portable professionnel dispose de 8 Go de RAM ! C’était sans compter le contexte du client qui partait à l’origine d’un Jira 3 qui tournait sur une machine avec 1 Go de RAM…

Le passage à Jira 4 n’avait pas posé de soucis « système », juste une mise à jour par export puis import des données, un peu fastidieuse mais rien de bien méchant. Le passage à Jira 6 s’annonçait comme devant se faire avec encore plus de facilité. Je demande alors à ce que l’on mette plus de mémoire à la machine virtuelle (sous Hyper-V) afin de prendre en considération le fait que Jira 6 nécéssite entre 1 et 2 Go de mémoire disponible.

On passe à 2 Go et bang ! L’application ne se lance pas. Pas de log, rien. Après quelques « echo on » je découvre que la JVM ne se lance pas car impossible d’allouer la mémoire pour le tas. Et quel tas ! voici ce que demandait la JVM:

java -XX:MaxPermSize=384m -Xms384m -Xmx768m

Nous sommes sous Windows Server 2003, je me dis alors que peut-être l’OS ne laisse pas assez de mémoire pour mon programme, qui ne réclasmme que 1,1 Go. On passe alors à 4 Go de RAM et en vérifiant qu’il restait encore 3,7 Go de libre mais rien n’y fait. La JVM ne peut s’initialiser.

Je pars alors dans une approche exploratoire pour découvrir qu’en modifiant les paramètres pour rester sous la barre des 1 Go, la JVM s’initialise et le programme se lance. Tout ce passait comme si la mémoire n’était pas accessible pour la JVM. Quelque pages googles plus tard je découvre les subtilités de Windows Server 2003, OS 32 bits qui partage en 2 le mémoire. Sur 4 Go, 2 pour les appliations et 2 pour l’OS (?). Ce partitionnement peut être changé par un paramétrage dans le fichier boot.ini. Malheureusement ce n’était pas ça.

Je commençais à sécher et à me retourner contre l’environnement de virtualisation. Le problême n’étant pas reproductible ailleurs: soit c’est l’OS, soit c’est la virtualisation. Que nenni ! il s’agit en fait d’une régression introduite en 2009 par un patch de sécurité de Microsoft (956572) qui du jour au lendemain avait privé les JVM de mémoire, du moi,s sous Windows Server 2003. Imaginez-vous votre serveur Tomcat avec 1024 Mo en Xmx qui marche bien puis qui ne marche plus sauf à la brider à 512 Mo en Xmx….. Heureusement que Microsoft a fourni un patch qui corrige le problème (kb971812)

Mais comme mon client n’avait que 1 Go de RAM et une JVM qui ne demandait que peu de ressource mémoire, le régression était passée inaperçue et aucun correctif installé. Voilà comment prendre quelques cheveux blancs.