You are not logged in.
Bonjour,
L'année dernière, j'avais migré vers GLPI 0.78.4. La migration de la base de données n'avait pas été simple : pour arriver à exécuter le programme, j'avais été obligé de déplacer le code PHP dans mon PC, doté plus confortablement en mémoire que le serveur.
Je viens de tenter la migration vers la dernière version (0.83.4), et là, même en exécutant le programme depuis mon PC, rien à faire : je n'ai pas assez de ressources disponibles. Il faut dire que la base de données a sérieusement augmenté en taille.
Bref, impossible de monter en version : je n'ai pas de machine assez puissante pour ça.
Pouvez-vous optimiser les scripts de telle manière qu'ils ne nécessitent pas une débauche de mémoire et de processeur ? J'aimerai éviter d'avoir tout à faire à la main... Quelques scripts SQL seraient bien plus efficaces qu'une programmation uniquement en PHP.
Si j'arrive à libérer suffisamment de temps, je regarderai comment c'est codé, pour en extraire les commandes SQL et les intégrer dans un script, mais c'est si j'ai du temps, ce qui n'est pas gagné... Si quelqu'un s'y est déjà collé, je suis preneur !
En attendant, je reste à la version 0.78, jusqu'aux prochaines vacances au moins (il ne faut pas qu'il y ait trop de monde pour pouvoir migrer cette appli).
Cordialement,
Éric Quinton.
Offline
Qu'est ce que t'appelle ne pas avoir assez de mémoire? 512 Mo de mémoire vive? parce que au dessus ça passe sans aucun soucis
Offline
2 Go, plus la mémoire virtuelle du poste... La migration, c'est à partir de la version 0.72.4, qui a vu la structure de la base être complètement modifiée. Et certaines de mes tables étaient particulièrement volumineuses.
Moralité, j'ai été obligé de réaliser des exports en CSV, et d'importer dans la nouvelle base, en générant les colonnes manquantes : 3 jours de boulot.
Dans des cas comme ça, la seule solution qui peut fonctionner avec tous les environnements, c'est d'exporter les tables dont la structure change du tout au tout dans des fichiers CSV, puis de les réinjecter dans la base de données. Vouloir tout traiter en mémoire "PHP", c'est aller au casse-pipe. Et pour le reste, il vaut mieux réaliser des scripts de modification en SQL natif, les SGBD sont optimisés pour ça. Cela peut nécessiter plus d'interventions des utilisateurs lors des migrations, mais au moins, on maîtrise ce qu'il se passe.
Je sais bien que la procédure actuellement utilisée est rapide à programmer, mais elle est trop gourmande en ressources. Je ne suis d'ailleurs pas le premier à avoir des problèmes, ce qui ne devrait pas être le cas avec un produit qui, autrement, est très bien fait et très complet.
À part ça, la nouvelle version a vraiment progressé par rapport à l'ancienne, la mise en place du support ITIL est un vrai plus. Merci au développeurs !
Offline
2 Go ca suffit largement pour migrer, vous devez avoir des soucis dans la configuration d'Apache, PHP et/ou MySQL
Offline