ERR : Le démarrage du processus IS Master est excessivement lent.
Description
Lorsque l’on lance les services P5 sous UNIX les processus se lancent mais sont tellement lents qu’on a presque l’impression que le démarrage a été stoppé. Les requêtes de démarrage peuvent mettre plusieurs dizaines minutes à apparaitre dans le fichier de log de l’Intranet Server Master.
Autres caractéristiques :
→ Pas d’erreur dans le fichier de log du processus Intranet Serveur Master.
→ La RAM du serveur n’est pas saturée et on ne swap pas.
→ La CPU reste faiblement utilisée.
Cause
La spécificité de ce problème est l’absence d’erreur applicative dans les logs P5. De plus dans le cas d’un manque de mémoire physique la SWAP aurait été utilisée. A l’extrême, la RAM et la SWAP auraient saturé et P5 renvoyé une erreur dans ses logs, ce qui n’est pas le cas ici.
Il s’agit donc plus vraisemblablement d’un problème de chargement des données depuis la Base de données (BDD). Le problème peut venir de la BDD elle-même ou de la communication entre les services P5 et la BDD. Ce peut être le cas lorsque la BDD et services P5 sont sur des serveurs distincts et que le paramétrage réseau ou le réseau lui-même est défaillant.
Résolution
Vérification de la BDD :
La première chose à faire est de vérifier que la BDD (et le serveur qui l’héberge) ne sature pas lorsque l’on démarre les services P5. Pour cela vérifier les éléments suivants sur le serveur de BDD :
→ Non saturation du CPU
→ Non saturation de la RAM
→ Non saturation des FS hébergeant les fichiers de BDD (en particulier les archivelogs)
→ Non saturation des tablespaces
Il doit être possible de se connecter à la BDD sans lenteur sur le serveur de BDD. Pour s’assurer que la BDD est bien en mesure de traiter des requêtes lancer une requête SQL en lecture sur la base (un « select » sur toutes les OPX2_TASK par exemple).
Si ces tests ne posent pas problème, passer à la vérification de la communication réseau.
Vérification de la communication réseau :
Cette vérification est pertinente sur une architecture pour laquelle la BDD est positionnée sur un serveur différent du serveur sur lequel tourne les Intranet Server P5.
Les points à vérifier peuvent être (liste non exhaustive) :
→ Absence d’erreur sur le chargement des interfaces réseau au démarrage du serveur : on peut afficher la log de démarrage sur un serveur en marche grâce à la commande « dmesg » lancée sous root. Le chargement des interfaces réseaux (ethX) est loggé et il est possible de voir et les erreurs éventuelles via cette commande.
→ Présence ou non d’erreur sur les paquets transmis/reçus : ces statistiques sont disponibles avec la commande « ifconfig » ou « netstat –i » :
[root@myserveur]# netstat -i
Kernel Interface table
Iface MTU Met RX-OK TX-ERR TX-DRP TX-OVR Flg
eth1 XXXX 0 XXXXXXX 0 0 BMRU
lo XXXXX 0 XXXXXX 0 0 0 XXXXXX 0 0 0 LRU
On constate qu’un certain nombre de paquets réseau sont en erreur sur l’interface eth1 (ici 57401 paquets en réception et aucun en émission) ce qui peut considérablement allonger le temps d’exécution des requêtes envoyées par P5 à la BDD et dégrader fortement le temps de chargement de l’instance Planisware Serveur.
On a un peu plus de détails sur les erreur rencontrés avec la commande « ifconfig » :
[root@myserveur]# a
eth1 Link encap:Ethernet HWaddr XX:XX:XX:XX:XX:XX
inet addr:XXX.XXX.XXX.XXX Bcast:XXX.XXX.XXX.XXX Mask:XXX.XXX.XXX.XXX
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:XXXXXXX errors: 57401 dropped:0 overruns:0 frame:56487
TX packets:XXXXXXX errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:XXXXXXXXX (X MiB) TX bytes:XXXXXXXXXX (X GiB)
Memory:d0080000-d00a0000
Pour rappel si on veut afficher le détail de la configuration d’une carte réseau on peut utiliser la commande « ethtool » suivie du nom de l’interface (ici eth1) :
[root@myserveur]# ethtool eth1
La résolution des problèmes liés à la configuration des interfaces réseaux peut être complexe nécessite ensuite le support d’une personne compétente en la matière pour vérifier la configuration réseau du serveur.
Cette vérification doit être menée sur les 2 serveurs (applicatifs et de BDD) pour s’assurer que des 2 côtés la configuration est correcte et ne génère pas d’erreur.
Enfin les configurations réseau sont correctes et que le problème persiste on pourra tester le réseau entre les 2 serveurs pour s’assurer qu’il n’y a pas de problème de routeur ou autre sur le réseau lui-même. Dans ce cas une expertise réseau est également indispensable.