-
Problème Tomcat et CPU
Bonjour,
J'ai une application Java (XMLRAD 2005 SR2, Tomcat 5.5) sur un serveur Windows 2000 qui, de façon apparemment aléatoire, fait utiliser 100% du temps CPU par Tomcat sans qu'il redescende : il faut arrêter et relancer Tomcat (et, parfois même, rebooter le serveur).
Il n'y a aucune boucle dans le source java de l'appli, et les requêtes (dans les stats) ne semblent jamais poser problème.
Les logs de tomcat n'indiquent rien de suspect, et les traces de l'application non plus...
L'application utilise entre autres plusieurs formulaires de type autocomplete (d'après les exemples du toolkit) et le composant DatePicker.
Donc, je suis un peu perplexe : je me doute bien qu'il s'agit d'un problème de l'application, mais je ne sais pas trop où chercher, ni quels tests faire pour tracer efficacement l'erreur...
Quelqu'un aurait une idée ?
Merci d'avance.
-
T'as pas réussi à isoler le ou les XMLServices concernés ?
Dans les stats, tu n'as aucune valeur maximale supspecte ?
Il faudrait que tu places toutes les traces à Verbose, et dès que tu rencontres la situation que tu décris, à ce moment ouvre le fichier des traces pour en savoir plus.
Peut-être trouveras tu des facteurs communs à chaque fois que le cas va se présenter.
à suivre ... !
-
Dans les stats, rien de vraiment anormal : parfois une requête en autocomplete un peu longue, mais qui ne provoque pas de time out.
Dans le fichier des traces en essayant de repérer l'instant de la montée du CPU à 100% (montée qui est instantanée et pas progressive...), il semblerait a priori que ça se déclenche lors d'un appel au service XMLC_PopupCalendar. Mais je n'en suis pas complètement sûr.
Y a-t-il possibilité d'avoir des traces encore plus verbeuses (actuellement, la variable XMLC_Trace est à 1) ?
-
oui dans l'eventlog, tu mets XML_TRaceVerbose à 1 et tous les groupes Verbose à 1
tu peux le faire dans XMLRAD, Resources, EventLog.
tu peux aussi désactiver l'Async pour que tu es la dernière traces avant plantage...
voir aussi:
http://xmlrad.com/DelosBin/Delos.dll...5#EventLog.xml
-
Bon, ça y est, on a trouvé d'où ça venait : c'est un service autocomplete qui provoquait la surcharge.
Pour résumer : le script qui gère le time out avait été exporté dans un js externe. Une variable globale (TimeOut) s'est retrouvée locale et, du coup, les objets s'entassaient dans la mémoire au lieu d'être détruits au fur et à mesure...
Donc maintenant, ça va mieux.
Merci de votre aide.
-