[0.72.1] Surcharge MySql sur inventaire logiciels

Eric26 · 2009-08-11 15:03:00

Bonjour à tous.

Nous rencontrons de très gros problèmes de performance lorsqu'on accède à l'inventaire des logiciels. S'il n'y a qu'une seule machine connectée à GLPI, cela fonctionne. C'est lent mais çà marche. Mais dès qu'une seconde machine se connecte, le process mysqld-nt.exe sature complètement notre serveur et la page de l'inventaire Logiciels ne s'affiche pas. Et uniquement l'inventaire logiciels ! Tous les autres inventaires s'affichent correctement et le process mysqld-nt.exe ne dépasse pas alors les 40% de temps processeur.

Pour info, voici la config du serveur :
- Serveur DELL Poweredge 2900
- Processeur INTEL XEON 2.8GHz
- 4 Go de RAM DDR3
- Espace disque disponible : 20Go
- OS : Windows 2003 standard
- Supporte un serveur IIS avec PHP et MySql (cf signature)
- Taille de la base GLPI sous MySql : 12,5 Mo

Ce serveur ne supporte que des applications Web dont GLPI est la "plus lourde" et sollicitant le plus le server MySql. D'où mon interrogation sur cette soudaine chute de performances.
J'ai déjà lu ce fil où il était déjà question de lenteurs sur l'inventaire des logiciels. Mais cela n'a jamais été jusqu'au point où nous sommes actuellement...

Y a-t-il une solution pour optimiser une cela ? Je peux fournir ici le contenu de mon fichier my.ini si çà peux aider.

Merci par avance !

ddurieux · 2009-08-11 15:05:22

Essayer d'optimiser la config de MySQL (par exmeple est configurant correctement le cache)

remi · 2009-08-11 15:05:52

Propositions
- Supprimer le comptage du nombre d'installations de la vue par défaut
- Utiliser un vrai OS de serveur
- Proposer le correctif

+

P.S. : combien de machines / logiciels ?

Eric26 · 2009-08-11 15:23:16

remi wrote:

Propositions
- Supprimer le comptage du nombre d'installations de la vue par défaut

Comment faire lorsque cette vue refuse de s'afficher ?

remi wrote:

- Utiliser un vrai OS de serveur
- Proposer le correctif

remi wrote:

P.S. : combien de machines / logiciels ?

474 machines et 243 logiciels. Cela ne me semble pas excessif. Je vais voir comment optimiser MySql...

Eric26 · 2009-08-11 18:22:43

J'ai vérifié les paramètres de MySql et j'ai cherché tout ce qu'il est d'usage de faire pour optimiser. Le seul truc qui n'était pas totalement optimisé était la taille du cache, je l'ai donc reconfiguré avec query_cache_size=32M.

Après redémarrage de MySql, dans l'état de MySql (via phpmyadmin) tous les voyants sont au vert. Mais le pb persiste. Pourtant, les pages s'affichent plus rapidement comme la page centrale, l'inventaire des ordinateurs, les moniteurs, etc... Sauf pour les logiciels : Dès qu'il y a plus d'un client connecté, la requête affiche une page blanche après une trentaine de secondes d'attente.

En mode débug... Bah, y a pas de mode débug ! Aucune info ne s'affiche.

Proposer un correctif ? Rien ne me ferait plus plaisir ! Au moins j'aurais l'honneur d'apporter ma pierre à l'édifice au lieu de rester "spectateur". Malheureusement, mes connaissances en PHP / MySQL sont limitées et mes tâches professionnelles ne me permettent pas de m'investir. Et d'un point de vue privé, je suis pris sur un autre projet d'application Web/Php/MySql qui m'accapare beaucoup plus que de raison (dixit mon épouse )...

Alors je ne désespère pas que les pro de GLPI trouvent une solution au problème. En attendant, je vais voir si je peux me dégoter un serveur qui ne ferait vraiment *que* l'hébergement de GLPI... Pourquoi pas avec "un vrai OS serveur"

Merci en tous cas, de tout le boulot fourni pour ce magnifique projet !

ddurieux · 2009-08-11 18:27:26

le mode debug se trouve dans les préférences utilisateurs, avec on pourrait voir quelle requete MySQL pose problème

JMD · 2009-08-11 19:51:32

Les problèmes de pages blanches sont souvent du au memory limit.

Essayez de l'augmenter dans votre php.ini et redémarrer apache

Eric26 · 2009-08-11 22:34:42

ddurieux wrote:

le mode debug se trouve dans les préférences utilisateurs, avec on pourrait voir quelle requete MySQL pose problème

Oui, je sais. J'ai bien activé le mode débug mais le pb se solde par une page blanche sans aucun trace du mode debug.

JMD wrote:

Les problèmes de pages blanches sont souvent du au memory limit.
Essayez de l'augmenter dans votre php.ini et redémarrer apache

J'avais déjà fixé le memory limit de php à 16M par le passé. Je vais voir à l'augmenter encore un peu demain, de retour au boulot.

Et je redémarrerai IIS bien qu'un serveur apache me plairait d'avantage... Mais on ne peut pas toujours avoir ce que l'on veut

Merci pour vos réponses. Je reposterai ici dès que...

ddurieux · 2009-08-11 23:07:18

oui le memory limit est vraiment... limite. Augmente le à 32 voire même 64 pour être tranquille

JMD · 2009-08-11 23:35:30

Oui c'est carrément insuffisant. Par défaut dans mes souvenirs, PHP5 est désormais paramétré avec 128M pour le memory limit.

Rien que pour un blog de type Wordpress, on demande 32 à 46 M...

remi · 2009-08-12 06:58:04

> avec on pourrait voir quelle requete MySQL pose problème
Ben on sait, c'est la jointure avec les installations...

> Le seul truc qui n'était pas totalement optimisé était la taille du cache
Vous avez passé un outil, genre mysqltunner ?

> 474 machines et 243 logiciels.
C'est clairement pas normal, ça passe chez moi avec une base "nettement" plus importante. (ok c'est un peu long).

> MySql 5.0.27
Plutôt ancienne comme version (oct 2006)...
MySQL a corrigé de nombreux bug, un test avec une version plus récente serait sans une bonne idée.

+

Eric26 · 2009-08-12 08:08:32

Eric26 wrote:

J'avais déjà fixé le memory limit de php à 16M par le passé.

Erratum .. le memory_limit est bien à 128M. Je n'avais pas accès au serveur lorsque j'ai posté cette annerie, hier. Désolé...

remi wrote:

Vous avez passé un outil, genre mysqltunner ?

Euh... Ce n'est pas un outil pour les systèmes Linux çà ?

remi · 2009-08-12 08:51:54

> Ce n'est pas un outil pour les systèmes Linux çà ?
C'est un script perl (donc ça peut marcher sur tout OS disposant de perl, y compris Windows)

+

Eric26 · 2009-08-12 10:04:04

Je crois que je viens de trouver la raison de mon problème : J'ai oublié de préciser que j'utilise la réplication de bases MySql avec un serveur esclave qui me sert de secours et de test.

Voulant mettre à jour la version de MySql, j'ai d'abord procédé sur ce serveur de secours avant le serveur de prod. En arrêtant le service MySql sur l'esclave, la réplication a pris fin automatiquement et, miracle .., plus de problème pour afficher l'inventaire des logiciels ! Même avec 5 clients connectés et actifs sur GLPI.

Le pb peut-il vraiment venir de là ? En tous cas, je vais quand même mettre à jour la version de MySql, des fois que cela améliore le moteur de réplication.

Eric26 · 2009-08-12 14:30:46

Bon, je crois que je viens de lever un lièvre (ou pas) !

Suite à mon message précédent, j'ai effectué les mises à jour de version pour MySql. Mes deux serveurs (prod et secours) sont en v5.1.37, soit la dernière version stable. J'ai vérifié les paramètres d'optimisation de PHP et MySql (cache et memory limit, entre autres).
J'ai remis en place la réplication native maitre-esclave de MySql entre les deux serveurs et mes essais d'affichage de l'inventaire logiciels se sont parfaitement bien déroulés (moins d' 1 seconde pour la génération de la page software.php).

Mais j'avais désactivé l'option de réplicat MySql intégrée dans GLPI pour éviter qu'une flopée de messages d'alerte n'encombre ma BAL. Et c'est en réactivant le réplicat MySql dans GLPI que la surcharge de MySql réapparait.

J'ai voulu en avoir le coeur net : Je me suis monté 2 machines virtuelles avec Windows 2003 (1 Go de RAM chacun) mais sans utiliser IIS. J'ai préféré y installer un Wampserver avec Apache 2.2.11, PHP 5.3.0 et MySql 5.1.36 par souci de rapidité et de facilité. Restauration d'un copie de ma BDD GLPI de travail sur chacun d'eux avec réplication MySql maitre-esclave.

Résultat :
- Module de réplicat MySql de GLPI inactif : Aucun pb pour accéder aux pages d'inventaire, logiciels compris. Temps de génération légèrement supérieur à 1 seconde.
- Module de réplicat MySql de GLPI actif (avec ou sans notification pas mail) : Impossible d'accéder à l'inventaire des logiciels.

Y a peut-être un bug là, non ?

Eric26 · 2009-08-19 08:42:45

Bonjour.

Après quelques jours d'absence, je reviens aux nouvelles sur ce problème. Personnellement, je reproduis systématiquement le phénomène lorsque le contrôle de la réplication MySql est actif dans GLPI.

Le bug est-il validé par l'équipe ?

[HS]PS : J'ai déjà fait plusieurs fois part de ma très grande satisfaction quant à ce super applicatif qu'est GLPI et à la réactivité de son équipe de Dev. Je la réitère ici avec mes plus vifs remerciements, soutenus par l'ensemble de mes collègues techniciens. Ils sont ravis par cette nouvelle version ! Bon courage pour la suite ![/HS]

remi · 2009-08-19 08:47:45

J'utilise un réplicat en prod (bon 0.71.6) sans aucun problème

De plus, même s'il est actif, aucune connexion sur le réplicat n'est réalisé lorsque GLPI fonctionne normalement (c'est à dire avec le maitre opérationnel)

Le réplicat n'est utilisé qu'en l'absence du maitre (ou pour quelques rapports gourmands)

Je suis donc très perplexe sur ce problème.

+

Eric26 · 2009-08-19 09:43:15

Oui, en 0.71.x, le pb ne se posait pas non plus chez nous.

Mais depuis... D'après moi, ce n'est pas vraiment la réplication proprement dite qui serait en cause, puisque MySql réplique nativement ces BDD vers un autre serveur lorsque configuré comme tel. Ce serait plutôt le contrôle de la réplication par GLPI (avec envoi d'un message lorsque la base de donnée GLPI est désynchronisée).

Actuellement, nous avons en prod 2 serveurs web dont 1 maitre MySql et 1 esclave avec GLPI 0.72.1 déployé. La réplication native de MySql fonctionne très bien et la navigation dans GLPI est très fluide (notamment pour l'accès à l'inventaire logiciels).

Si j'active l'option de réplication MySql dans GLPI, avec ou sans notification pas mail en cas de désynchro, la navigation dans GLPI devient plus lente et quasiment impossible pour l'inventaire logiciels. Le process mysqld-nt sature le processeur du serveur maitre pendant une durée variable (env. 1 à 2 min) rendant GLPI inexploitable.

J'ai extrait une image virtuelle de ces deux serveurs et j'ai restauré une version 0.71.5 de GLPI avec sa BDD sur chacun d'eux. Ainsi, contrairement à ce que j'avais fait auparavant, je suis dans le même conditions que la prod (IIS en non Wampserveur, lors de mon premier test). Ils fonctionnent sur le même principe que ceux en prod (1 maitre répliqué sur 1 esclave). Dans ce cas, que l'option de réplication MySql de GLPI soit active ou non, il n'y a strictement aucun souci de navigation.

Il est vrai que les requêtes pour l'inventaire des logiciels se sont un peu alourdies depuis 0.72.x et je comprends la problématique. Mais je doute que ce soit la seule cause de la surcharge.

remi · 2009-08-19 10:14:33

étrange.

La seule requete que passe le cron de controle est un

 SELECT UNIX_TIMESTAMP( MAX( date_mod ) ) AS max_date FROM glpi_history

Exécutée en direct, elle retourne quoi et en combien de temps ?
L'index sur date_mod est-il bien présent ?

Que retourne

EXPLAIN SELECT UNIX_TIMESTAMP( MAX( date_mod ) ) AS max_date FROM glpi_history

Normalement

1      SIMPLE      NULL      NULL      NULL      NULL      NULL      NULL      NULL      Select tables optimized away

qui indique que c'est instantané (pas de lecture de la table)

Bien sur, à tester sur les 2 serveurs

Cette tâche est exécuté toutes les 5', mais il est possible d'augmenter l'interval (cron.class.php, ligne 134)

$this->taches["dbreplicate"]=300;

+

Eric26 · 2009-08-19 10:32:06

remi wrote:

La seule requete que passe le cron de controle est un
 SELECT UNIX_TIMESTAMP( MAX( date_mod ) ) AS max_date FROM glpi_history
Exécutée en direct, elle retourne quoi et en combien de temps ?

Cette requête retourne (sur le 2 serveurs) :

Affichage des enregistrements 0 - 0 (1 total, Traitement en 0.0007 sec.)

avec le résultat :

max_date
1250666561

remi wrote:

L'index sur date_mod est-il bien présent ?
Que retourne
EXPLAIN SELECT UNIX_TIMESTAMP( MAX( date_mod ) ) AS max_date FROM glpi_history
Normalement
1      SIMPLE      NULL      NULL      NULL      NULL      NULL      NULL      NULL      Select tables optimized away
qui indique que c'est instantané (pas de lecture de la table)

Je confirme. J'ai bien :

1     SIMPLE      NULL      NULL      NULL      NULL      NULL      NULL      NULL     Select tables optimized away

pour les 2 serveurs.

remi wrote:

Cette tâche est exécuté toutes les 5', mais il est possible d'augmenter l'interval (cron.class.php, ligne 134)
$this->taches["dbreplicate"]=300;

Je vais voir çà...

remi · 2009-08-19 10:38:49

Quand l'application coince, que renvoie un SHOW PROCESSLIST ?

En particulier quelle est la requête qui tourne et bloque les autres en "lock"..

+

P.S. activer le slow_query_log me semble aussi judicieux pour détecter la source des problèmes.

Eric26 · 2009-08-19 11:56:33

Voici le SHOW PROCESSLIST lorsque l'accès à l'inventaire Logiciels coince (option Replicat MySql = ON) :

mysql> show processlist;
+------+---------+---------------------------+------+-------------+-------+-----
-----------------------------------------------------------+--------------------
--------------------------------------------------------------------------------
--+
| Id   | User    | Host                      | db   | Command     | Time  | Stat
e                                                          | Info

  |
+------+---------+---------------------------+------+-------------+-------+-----
-----------------------------------------------------------+--------------------
--------------------------------------------------------------------------------
--+
| 2157 | replica | PREF26-SAPP01:3647        | NULL | Binlog Dump | 16978 | Has
sent all binlog to slave; waiting for binlog to be updated | NULL

  |

| 2845 | root    | localhost:2668            | NULL | Query       |     0 | NULL
                                                           | show processlist

  |
| 2890 | root    | pref26-sapp02.at.int:2714 | glpi | Query       |     6 | Copy
ing to tmp table                                           | SELECT glpi_softwar
e.FK_entities, glpi_software.recursive, glpi_software.name AS ITEM_0, glpi_softw
a |
+------+---------+---------------------------+------+-------------+-------+-----
-----------------------------------------------------------+--------------------
--------------------------------------------------------------------------------
--+

J'ai refais le SHOW PROCESSLIST avec l'option Replicat MySql sur OFF et la dernière requête "Copy to tmp table ..." n'apparait plus. J'ai refais le test plusieurs fois et c'est flagrant.

PS : Activer slow_query_log ? Dans la config MySql ?

Forum GLPI-Project

Announcement

#1 2009-08-11 15:03:00

[0.72.1] Surcharge MySql sur inventaire logiciels

#2 2009-08-11 15:05:22

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#3 2009-08-11 15:05:52

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#4 2009-08-11 15:23:16

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#5 2009-08-11 18:22:43

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#6 2009-08-11 18:27:26

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#7 2009-08-11 19:51:32

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#8 2009-08-11 22:34:42

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#9 2009-08-11 23:07:18

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#10 2009-08-11 23:35:30

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#11 2009-08-12 06:58:04

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#12 2009-08-12 08:08:32

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#13 2009-08-12 08:51:54

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#14 2009-08-12 10:04:04

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#15 2009-08-12 14:30:46

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#16 2009-08-19 08:42:45

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#17 2009-08-19 08:47:45

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#18 2009-08-19 09:43:15

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#19 2009-08-19 10:14:33

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#20 2009-08-19 10:32:06

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#21 2009-08-19 10:38:49

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

#22 2009-08-19 11:56:33

Re: [0.72.1] Surcharge MySql sur inventaire logiciels

Board footer