Lenteur variable en fonction des utilisateurs glpi

lozair · 2010-02-12 13:59:40

Bonjour,
Nous rencontrons actuellement un problème de lenteur pour remonter la liste de tous les ordinateurs (plus généralement tous les inventaires) insérés dans GLPI.
Cette lenteur est présente pour certains utilisateurs et pas pour d'autres.....

Ci dessous la description de notre installation :

* 1 frontend http (apache 2.2.3 + php-mysql 5.1.6-24) heberge sur une machine virtuelle linux centos
* 1 backend bdd heberge sur une machine physique linux centos(bi-pro dual core 8 Go de RAM) en mysql 4.1.22. Le serveur de bdd est partagé avec d'autres petites bases mais ne présente aucune saturation particulière.

Concernant GLPI, version 0.72.21.
Autentification externe sur un serveur CAS.
Import des données utilisateurs via une connexion LDAP.
Nombre d'ordinateurs dans glpi ~ 2500
Nombre d'entite dans glpi ~ 10
Utilisation de 2 plugins : mas-ocsimport + gestion des achats

Description détaillée du problème :
* Lorque le user1 lance un inventaire d'ordinateur, glpi affiche le resultat environ 40 secondes apres.
* Lorsque le user2 lance un inventaire d'ordinateur, depuis la meme machine cliente, glpi affiche le resultat en moins d'une seconde.

La différence de temps de traitement se fait au niveau du serveur mysql.
La requete mysql genere par le user1 met 40 secondes pour s'executer sur le serveur mysql.
La requete mysql genere par le user2 met 1 secondes a s'executer sur le serveur mysql.

En passant en mode debug, on se rend compte que les requetes sont exactement les meme a la difference de la ligne suivante :
Pour user1 on a une clause : WHERE glpi_computers.deleted='0' AND glpi_computers.is_template='0' AND ( glpi_computers.FK_entities IN ('2','11','9','10','13','12') ) GROUP BY glpi_computers.ID

Pour user2 on a une clause: WHERE glpi_computers.deleted='0' AND glpi_computers.is_template='0' GROUP BY glpi_computers.ID

Cela parait normal puisque le user2 est en fait super-admin dans glpi de l'entite racine alors que le user1 à differents droits dans differentes entites.

La ou cela se complique c'est qu'en prenant exactement la meme requete genere par le user1 (qui met environ 40 secondes a s'executer sur le serveur mysql) et en la lancant depuis un simple script php depuis la meme machine on obtient invariablement une reponse en moins de 1 seconde.

Bref nous penchions au départ a une problématique mysql mais les tests menés avec mysql_tunner et les paramétrages effectués sur le serveur mysql nous font pensé qu'il existe peut être un problème dans notre configuration de GLPI.

La seule chose qui permette de resoudre le probleme pour le user1 est de purger son compte et de le recréer. Dans ce cas la tout fonctionne normalement. Probleme, en purgeant l'utilisateur, celui ci perd tous les liens vers les tickets, etc... ce qui n'est pas possible sur notre plateforme de production.

Aussi nous sommes à la recherche de pistes/idées pour résoudre ce problème.

Merci d'avance

lozair · 2010-02-17 18:10:10

Bonjour,

Je reviens sur notre problème.
Personne n'aurais une idée/piste.......
Si des précisions manquent, nous somme pret a les fournir.
globalement on se demande si notre problème est purement local ou a deja ete rencontré par d'autres utilisateurs de GLPI ?

Merci pour votre aide

JMD · 2010-02-17 20:04:30

Désolé de ne pas avoir répondu. J'avais lu précédemment et avec attention votre message mais sans avoir de pistes exploitables.

J'ai eu le tour au boulot mais c'était un utilisateur qui affichait une tonne de colonnes suplémentaires lors de ses recherches. Forcément ça faisait ramer.

Pourriez vous peut-être mettre explicitement la requête qui pose problème ?

Sinon autre question, le temps de latence est systématique ? Aléatoire ? Depuis le début ?

Vous avez essayé sur une autre serveur de DB ? ou en local sur une bécane ? Pour éliminer la cause serveur.

ddurieux · 2010-02-17 20:12:48

Ca pourrait venir du cache de MySQL
En effet, si la première fois la requete est envoyée, mysql fait la recherche et la met en cache. Un autre utilisateur ou en utilisant directement la requete dans mysql, il va sortir le resultat du cache de MySQL.

Afin de tester, redémarer MySQL et réessayer la requete, elle devrais mettre 30 - 40 secondes.

lozair · 2010-02-18 10:00:01

merci pour vos réponses.

Ci dessous la requête de l'utilisateur :

**********************************************************
SELECT glpi_computers.name AS ITEM_0, glpi_computers.ID AS ITEM_0_2, glpi_entities.completename AS ITEM_1, glpi_entities.ID AS ITEM_1_2, GROUP_CONCAT( DISTINCT CONCAT(glpi_contracts.name,'$$' ,glpi_contracts.ID) SEPARATOR '$$$$') AS ITEM_2, glpi_dropdown_state.name AS ITEM_3, glpi_dropdown_manufacturer.name AS ITEM_4, glpi_computers.serial AS ITEM_5, glpi_type_computers.name AS ITEM_6, glpi_dropdown_model.name AS ITEM_7, glpi_dropdown_os.name AS ITEM_8, glpi_dropdown_locations.completename AS ITEM_9, glpi_computers.date_mod AS ITEM_10, glpi_computers.contact AS ITEM_11, glpi_users_FK_users.name AS ITEM_12, glpi_users_FK_users.realname AS ITEM_12_2, glpi_users_FK_users.ID AS ITEM_12_3, glpi_users_FK_users.firstname AS ITEM_12_4, GROUP_CONCAT( DISTINCT glpi_networking_ports.ifmac SEPARATOR '$$$$') AS ITEM_13, GROUP_CONCAT( DISTINCT DEVICE_5.specificity SEPARATOR '$$$$') AS ITEM_13_2, GROUP_CONCAT( DISTINCT glpi_networking_ports.ifaddr SEPARATOR '$$$$') AS ITEM_14, SUM(DEVICE_3.specificity) / COUNT( DEVICE_3.ID) * COUNT( DISTINCT DEVICE_3.ID) AS ITEM_15, glpi_groups.name AS ITEM_16, glpi_computers.ID AS ID FROM glpi_computers LEFT JOIN glpi_entities ON (glpi_computers.FK_entities = glpi_entities.ID) LEFT JOIN glpi_contract_device ON (glpi_computers.ID = glpi_contract_device.FK_device AND glpi_contract_device.device_type='1') LEFT JOIN glpi_contracts ON (glpi_contract_device.FK_contract = glpi_contracts.ID) LEFT JOIN glpi_dropdown_state ON (glpi_computers.state = glpi_dropdown_state.ID) LEFT JOIN glpi_dropdown_manufacturer ON (glpi_computers.FK_glpi_enterprise = glpi_dropdown_manufacturer.ID) LEFT JOIN glpi_type_computers ON (glpi_computers.type = glpi_type_computers.ID) LEFT JOIN glpi_dropdown_model ON (glpi_computers.model = glpi_dropdown_model.ID) LEFT JOIN glpi_dropdown_os ON (glpi_computers.os = glpi_dropdown_os.ID) LEFT JOIN glpi_dropdown_locations ON (glpi_computers.location = glpi_dropdown_locations.ID) LEFT JOIN glpi_users AS glpi_users_FK_users ON (glpi_computers.FK_users = glpi_users_FK_users.ID) LEFT JOIN glpi_computer_device AS DEVICE_5 ON (glpi_computers.ID = DEVICE_5.FK_computers AND DEVICE_5.device_type='5') LEFT JOIN glpi_networking_ports ON (glpi_computers.ID = glpi_networking_ports.on_device AND glpi_networking_ports.device_type='1') LEFT JOIN glpi_computer_device AS DEVICE_3 ON (glpi_computers.ID = DEVICE_3.FK_computers AND DEVICE_3.device_type='3') LEFT JOIN glpi_device_ram ON (DEVICE_3.FK_device = glpi_device_ram.ID) LEFT JOIN glpi_groups ON (glpi_computers.FK_groups = glpi_groups.ID) WHERE glpi_computers.deleted='0' AND glpi_computers.is_template='0' AND ( glpi_computers.FK_entities IN ('2','11','9','10','13','12') ) GROUP BY glpi_computers.ID ORDER BY ITEM_0 ASC LIMIT 0, 10000;"
**********************************************************************************

Concernant le temps d'attente il est systematique pour plusieurs utilisateurs alors que pour d'autres il est systématiquement de l'ordre de la seconde.....

Le retour utilisateur semble montrer que les lenteurs sont apparues progressivement au fil de l'utilisation de GLPI. Notre installation est en production depuis septembre 2009.

Nous allons migrer notre base de test vers un autre serveur mysql en version 5 pour voir si les lenteurs sont toujours présentes.

A priori nous avons deja fait le test par rapport au cache mysql et les utilisateurs qui ont des problèmes sont toujours les mêmes.

lozair · 2010-02-19 09:46:18

Bonjour,

Suite à vos conseils nous avons migré nos bases glpi vers un nouveau serveur mysql qui est en version 5 (machine beaucoup MOINS puissante).
Nous avons utilisé le dump de l'ancien serveur.
Resultat, tout fonctionne ......!
Plus aucune lenteur quel que soit l'utilisateur.....
Difficile donc d'identifier le problème originel...
Pour info il semble que sur mysql 4 nous arrivions à resoudre le probleme en changeant l'id de l'utilisateur subissant des lenteurs et en reaffectant ce nouvel id dans toutes les tables glpi pour qu'il conserve ses tickets, historique, etc...

Bref pour nous tout est maintenant OK.

Merci encore pour votre aide

doum · 2010-02-19 10:22:58

Ok, tant mieux

Je ferme

JMD · 2010-02-19 13:12:19

Humm ça reste tout de même mystérieux comme dysfonctionnement, à suivre...

doum · 2010-02-19 14:13:31

Faut rouvrir le sujet alors ?

Forum GLPI-Project

Announcement

#1 2010-02-12 13:59:40

Lenteur variable en fonction des utilisateurs glpi

#2 2010-02-17 18:10:10

Re: Lenteur variable en fonction des utilisateurs glpi

#3 2010-02-17 20:04:30

Re: Lenteur variable en fonction des utilisateurs glpi

#4 2010-02-17 20:12:48

Re: Lenteur variable en fonction des utilisateurs glpi

#5 2010-02-18 10:00:01

Re: Lenteur variable en fonction des utilisateurs glpi

#6 2010-02-19 09:46:18

Re: Lenteur variable en fonction des utilisateurs glpi

#7 2010-02-19 10:22:58

Re: Lenteur variable en fonction des utilisateurs glpi

#8 2010-02-19 13:12:19

Re: Lenteur variable en fonction des utilisateurs glpi

#9 2010-02-19 14:13:31

Re: Lenteur variable en fonction des utilisateurs glpi

Board footer