[RESOLU] Openoffice monte la charge CPU à 100 %

[legaulois]

Ola,

je viens à vous suite à un problème rencontré.

Il semblerait que une fois que tomcat est démarré, et à forciori openoffice aussi, la charge CPU monte à 100% d'utilisation.
Ce qui est problématique.

Si j'effectue un stop /etc/init.d/ooffice stop, la charge CPU revient à un niveau normal. Par contre : plus de vignettes, plus de preview.

J'utilise sysstat pour avoir les stats systèmes.

La machine virtuelle dispose de 3 gigas de ram et 2 VCPU.

Je tourne avec Alfresco 3.2r2 sous CentOS 5.4.

Quelqu'un a t'il déjà rencontré ce problème ?

[rguinot]

Au moment ou la charge est à 100% de CPU, faites un thread dump sur le process (kill -3 sur le PID).
On verra alors ce que les threads font

[legaulois]

Les deux process liés à Tomcat

tomcat    7065     1  8 15:51 ?        00:00:33 /usr/lib/jvm/java/bin/java -Dcatalina.ext.dirs=/usr/share/tomcat5/shared/lib:/usr/share/tomcat5/common/lib -D
tomcat    7152  7065 67 15:51 ?        00:04:19 /opt/openoffice.org3/program/soffice.bin -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManage‍‍

J'ai donc fait un "kill -3 7152"

Et la liste des process ne change pas, par contre, les charges CPU ont l'air de se sentir mieux.

Je recheck dans une minute puis je ferai un restart tomcat pour voir

[rguinot]

le kill -3 ne peut en aucun cas changer la charge CPU.

normalement vous devriez avoir un dump de l'état des threads dans la console, ou dans le catalina.out ou alfresco.log en fonction de votre config de logging.
autre option, jstack lvmid, en remplaçant lvmid par l'id de la jvm obtenu par la commande jps (bootstrap probablement si vous tournez sous tomcat)

[legaulois]

Ouech bah disons que j'ai aucune trace dans alfresco.log ou catalina.out :s

Cela dit ça a l'air d'être rentré à la normale :s

Va comprendre.

J'vais surveiller ça de près, je controlerai demain matin.

[rguinot]

quel est le process qui est à 100% java ou soffice ?
il faut faire le kill -3 sur le process qui est à 100%

[legaulois]

Problème résolu dans l'immédiat, ça devait être les paramètres JVM qui petaient une zin depuis le basculement sur la ferme VMware de prod. J'ai maintenant adapté les paramètres de la JVM et ça tourne au poil.