Problême pour passer de GLPI 0.68.3-2 à la 0.7

etiennekraemer · 2008-01-08 16:52:20

Bonjour,

me revoilà avec mes soucis.
J'ai essayé de faire la mise à jour de la 0.68.3 vers la 0.7 mais lors de la mise à jour de la base de donnée (elle fait au moins 15 Mo) ça avance à 1% puis 2% puis 3% puis 4% puis ensuite ça s'arrête.
Quel serait ce soucis ?

Merci d'avance

MoYo · 2008-01-08 19:31:01

Sans ca :
http://glpi-project.org/forum/viewtopic.php?id=128

vous n'aurez pas de réponse.

etiennekraemer · 2008-01-08 19:55:41

Procédons par chronologie :

La version de GLPI que vous utilisez (numéro de version) et si vous avez réalisé une mise à jour la version de départ et celle d'arrivée : 0.68.3

La plateforme sur laquelle vous l'avez installé : win/mandrake/debian ... : Windows XP en locale
Je travail avec Movamp :
Mov'AMP 0.6 :

* Apache 2.0.59
* MySQL 4.1.22-community
* PHP 5.2.3
* phpMyAdmin 2.11.0

Navigateur utilisé (IE, Moz...) et version : Mozilla 2.0.0.6

Les manipulations que vous avez effectuées : J'ai suivi la procédure décrite dans le fichier LISEZ.MOI du fichier glpi-0.70.tar.gz

Les messages d'erreur de GLPI en mode debug : Aucun mais lors de la mise à jour de la base de donné, la barre de défilement s'arrête à 4% puis plus d'avancé.

Voilà

MoYo · 2008-01-08 20:03:06

vous pouvez essayer d'augmenter le time_out php pour voir si ca fonctionne mieux.

JMD · 2008-01-08 20:08:19

Augmentez également le memory limit de votre php.ini et relancez apache

La mise à jour consomme pas mal de mémoire si votre DB est importante.

MoYo · 2008-01-08 20:15:51

bonne idée ca effectivement
meilleure que la mienne je pense.

etiennekraemer · 2008-01-08 20:21:29

OK, je vais voir cela.

msp · 2008-01-09 17:59:52

J'ai le même problème sauf que ça gèle à 46 % en plus d'avoir le problème des caractères accentués
Installation sur FreeBSD à partir des port sur un p4 3.2Ghz avec 512Mo de RAM

Apache 2.2.6
PHP 5.2.5
Mysql 5.0.51

J'ai mis memory_limit à 256M dans php.ini mais rien ne change toujours le même problème

J'ai essayé avec IE6 et firefox 2.0.0.11
ma db pour glpi fait environ 100Mo
la sauvegarde ne se fait pas par l'interface glpi c'est trop long, elle se fait la nuit par un script

Lorsque j'envoie l'update, je la laisse tourner pendant 3h et je vois rien bouger excepté le processus mysqld qui occupé 90% du CPU
D'ailleurs j'ai le même problème si je fais la sauvegarde par l'interface mais par la je vois que le fichier .sql augmente tranquillement mais au rythme ou ça va ça peut prendre 6h..

A chaque fois il faut que je redémarre mysql pour que je puisse réutiliser l'interface

JMD · 2008-01-09 18:59:29

humm là effectivement ça peut être long.

Pour les sauvegardes, il est évident que vu la taille, il faut passer par la ligne de commande.

Mais bon pour l'update si les réglages du php.ini le permettent ça devrait fonctionner.

msp · 2008-01-09 20:56:51

OK ben je vais renvoyer l'update et je vais attendre jusqu'à demain matin pour voir ce que ça donne
J'ai gonflé les valeurs dans php.ini :
max_execution_time = 360
max_input_time = 360
memory_limit = 256M

Je vous tiendrais au courant
Merci

JMD · 2008-01-10 00:05:30

En fait le passage 0.68 -> 0.7 est fortement gourmand car pour le passage en full utf8, l'ensemble du contenu de la DB est converti. Dans votre cas ça fait tout de même beaucoup de volume.

Bref, c'est une grosse update qui a un caractère tout de même exceptionnel.

msp · 2008-01-10 15:45:54

Bon comble de malchance hier soir on a eu des coupures électriques et la machine n'est pas beanché sur un UPS donc l'update ne s'est pas terminée je la renvoie ce matin peut-être en fin d'après-midi elle sera terminée.

Peut-être qu'il faudrait une solution alternative en ligne de commande moins gourmande pour ceux qui ont des gros parcs (ici on a 3500 postes inventoriés, bien plus de logiciels...)

JMD · 2008-01-10 20:08:15

Certe mais ça veut dire double de travail et on a beau avoir de plus en plus d'utilisateurs y compris gros parcs, on a pas plus de contributions humaines ou financières... C'est bien dommage.

MoYo · 2008-01-10 20:10:06

3500 postes ce n'est vraiment pas grand chose.

en ligne de comande ce ne sera pas forcement moins gourmand.
Vous parlez de la mise à jour du contenu il est forcement long et un système de reload est prévu pour qu'il aboutisse normalement querlquesoit la configuration de timeout (ca ne prend pas en compte la mémoire effectivement)

Les pourcentages dépendent des tables et ne sont donc pas complètement significatifs.
il va passer beaucoup de temps sur les grosses tables sans pour autant augmenter en pourcentage.

msp · 2008-01-10 22:49:22

JMD wrote:

Certe mais ça veut dire double de travail et on a beau avoir de plus en plus d'utilisateurs y compris gros parcs, on a pas plus de contributions humaines ou financières... C'est bien dommage.

Je veux bien mais pour le moment j'en suis au stade à faire accepter le produit auprès de mes supérieurs pour les contributions financières on verra plus tard lorsque il restera plus que des bugs mineurs.
C'est déjà dur de faire rentrer du libre dans la fonction publique si en plus au bout de 3 mois tu leur dit qu'il faudrait qu'il paye pour contribuer au développement du projet...
Déjà qu'on peut même pas se faire payer de café...
Je m'égare.
Il faut pas oublier aussi que le rapport de problèmes est une contribution humaine en soit.

D'ici un an si tout va bien et que le projet est apprécié, j'essaierai de pousser pour qu'il contribue financièrement mais sachant qu'il faudrait aussi contribuer à OCS qu'on utilise...

Bref je fais de mon possible.

Last edited by msp (2008-01-10 22:50:12)

JMD · 2008-01-11 01:51:58

Je disais pas ça spécialement pour vous. Chaque situation est particulière. Ma remarque est générale.

Oui le rapport de problème est une contribution en soit (cf notre site où nous l'expliquons), Toutefois il en faut pas se méprendre sur le fait que si il y a beaucoup de personne pour remonter des problèmes, il en faut aussi pour les résoudre...

Quand à la contribution financière, il ne faut pas se méprendre sur les sommes et ne pas oublier de comparer ce qui doit l'être.

Les versions stables sont téléchargées environ 40 000 fois, si chaque téléchargement occasionné un versement d'un euro. Le projet GLPI disposerait de 40 000 euros pour fonctionner.

Ou, autre exemple, si les 1200 structures ayant déclarés utiliser GLPI pour gérer leur parc faisaient un don annuel de 50 euros. Le projet GLPI disposerait de 60 000 euros pour fonctionner.

Vous voyez que ces dons sont loin de mettre l'équilibre financier de nos chères entreprises ou insititutions publiques en péril. Et que nous serions bien au dessus des 1000 euros de dons que nous recevons chaque année...

Bonne soirée et continuez bien sur de faire votre possible

msp · 2008-01-11 16:13:36

Bon ce matin l'update s'est finalement terminée, toutes les tables sont migrées en UTF8.
Maintenant faut que je corrige les mot tronqués avec les accents...
Merci beaucoup pour votre aide

Last edited by msp (2008-01-11 16:24:28)

JMD · 2008-01-11 20:51:19

Les mots tronqués avec les accents c'est pas normal.

Forum GLPI-Project

Announcement

#1 2008-01-08 16:52:20

Problême pour passer de GLPI 0.68.3-2 à la 0.7

#2 2008-01-08 19:31:01

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#3 2008-01-08 19:55:41

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#4 2008-01-08 20:03:06

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#5 2008-01-08 20:08:19

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#6 2008-01-08 20:15:51

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#7 2008-01-08 20:21:29

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#8 2008-01-09 17:59:52

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#9 2008-01-09 18:59:29

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#10 2008-01-09 20:56:51

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#11 2008-01-10 00:05:30

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#12 2008-01-10 15:45:54

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#13 2008-01-10 20:08:15

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#14 2008-01-10 20:10:06

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#15 2008-01-10 22:49:22

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#16 2008-01-11 01:51:58

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#17 2008-01-11 16:13:36

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

#18 2008-01-11 20:51:19

Re: Problême pour passer de GLPI 0.68.3-2 à la 0.7

Board footer