Comment vérifier l'intégrité de la DB sous scenariserver4.2 ?

Bonjour
la migration de scenariserver 4.1 vers 4.2 sous tomcat 8 s’est passée sans trop de problème grâce à la documentation disponible.
Mais fréquemment, lors de l’ouverture d’un atelier, on a le message “mise à jour de l’étalier impossible”

En effaçant les fichiers _checkSumDb.txt tout semble rentrer dans l’ordre. Mais nous devons refaire cela fréquemment. Il y a un souci de cohérence quelque part et on ne sait pas comment réaliser le test d’intégrité de la DB.
Quelqu’un pourrait-il nous aider pour solutionner le problème acr c’est notre serveur de production
Merci d’avance
Atika

Bonjour Atika,

Votre serveur d’application (ou serveur) doit se stopper fréquemment de façon « non propre » (ie sans utiliser les services de fermeture standards).

Les logs applicatifs doivent indiquer ce type de problème.

Dans tous les cas, c’est très inquiétant sur la stabilité du système : il faut résoudre ce problème avant d’utiliser cet environnement en production.

Cordialement,

Antoine

Bonjour Antoine,
je te remercie pour ton diagnostic.
Je suis inquiète et je me demande concrétement comment faudrait-il procéder ?
Merci pour ton retour
Bien cordialement
Atika

Il faut te rapprocher de ton administrateur applicatif serveur.

L’installation, le monitoring et la gestion (sauvegardes, …) d’un environnement serveur exploitant une base de données requiert une administration technique très rigoureuse.

Antoine

Merci Antoine,
Laurent qui est notre administrateur va fournir plus d’information pour décrire le problème.
Merci de votre collaboration
Atika

Bonjour,

Voici plus d’information sur la configuration :
Le serveur Scenari est sur un Debian 8
Installation via apt-get
java version “1.7.0_121”
Tomcat: 8.0.14
Authentification des utilisateurs en LDAP.

Je remarque que lors d’une mise à niveau d’un atelier (à confirmer), des processus occupent 100% du CPU du serveur en continue.


Cela a pour effet de causer un plantage de Tomcat qui m’oblige de relancer Tomcat.
Si je redémarre Tomcat avant le plantage, cela ne semble pas poser problème et l’utilisation du CPU redevient à la normale.

Je profite aussi de ce message pour vous faire par d’une question :
Est-il normal que je n’aie rien quand je consulte cette page : http://xxx.xxx.xxx.xxx:8080/scenariserver4.2/s/chain/u/ping ? j’ai une page blanche et dans la console du navigateur j’ai 401 - noAuthenticationDatas
Il y a peut-être une configuration à réaliser sur TomCat.
Cela m’intéresse car j’ai la même page blanche pour le test d’intégrité de la DB.

Merci d’avance pour votre aide,
Laurent

Une première remarque : vous avez aloué combien de RAM au Java de Tomcat, il a l’ai de n’occuper que 272Mb ce qui est ridicule pour un SCENARIserver su un serveur qui propose 8Gb. vous avez bien modifié /etc/defaults/tomcat8 pour modifier les paramètres XMX et XMS ?

Pour la page ping, oui c’est normal, elle est bien vide.

Merci pour votre réponse.
Effectivement -Xms1024M -Xmx1024M n’était pas définit.

C’est chose faite,les processus Tomcat sont à 449M après un redémarrage (j’imagine que c’est normal au début).

Je remarque encore le problème de processus qui utilise 100% du CPU (voir capture du post plus haut). Cela semble se produit plusieurs heures après un redémarrage.

J’aimerais tester l’intégrité des données de la DB mais http://xxx.xxx.xxx.xxx:8080/scenariserver4.2/s/chain/u/adminOdb?cdaction=CheckAuto

Me donne aussi une page blanche et je ne reçois pas de demande d’identification.

Bonjour,

Votre URL de checkAuto est incorrecte (/chain en trop)/ Je vous invite à consulter la documentation sur ce sujet : https://docs.kelis.fr/sc42/scsrv/adminTech/lin/co/monitoring.html

Une page blanche ne signifie pas que la requête n’a pas abouti. C’est le code http de retour (200) qu’il faut vérifier et qui est l’indicateur de réussite ou d’échec.

Les interrogations via « /s » doivent s’accompagner d’une authentification « basic auth » (via les sondes nagios par exemple). Pour obtenir un prompt d’authentification, il faut remplacer /s par /web.

Pour le pb de CPU, il faut comprendre l’origine du pb en analysant quel processus consomme 100% de cpu…

Cdt

Antoine

Kelis

Effectivement je n’avais pas compris la différence avec le /web le /s.
Je comprends mieux le code de retour 401 que j’obtenais.

Pour info : desc="Check db auto ok in 4410ms.

Me reste le problème des processus qui utilisent le CPU à 100% comme illustré dans la capture d’écran dans la 1er poste.

/usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

Merci encore pour votre aide,
Laurent

Vous utilisez quelle version de SCENARIchain-server ?

Si ça n’est pas une version récente, vous pouvez retester avec https://download.scenari.software/SCENARIchain-server@4.2.1.03/ ?

Cdt

Antoine

Kelis

Voici la version installé : scenariserver4.2:all/jessie 4.2.103-s1 uptodate

Pour le moment, le serveur semble stable, mais je continue le monitoring.
Je regarde aussi pour appliquer une mise à jour de tomcat 8 (8.0.14-1+deb8u6 --> 8.0.14-1+deb8u8).

Bien à vous,
Laurent