You are not logged in.
Pages: 1
Bonjour,
Je rencontre un souci avec ma table glpi_logs qui explose ...
Lorsque j'essaye de lancer une purge via purgelogs, rien ne se passe la tâche ne termine jamais (plus d'une nuit) et j'ai même l'impression que suite à cela la table a encore considérablement augmentée.
Est-ce que quelqu'un possède un script à exécuter via mariaDB pour supprimer d'anciens logs (j'aimerai supprimer tout ce qui est plus vieux d'un an, voir 6 mois).
Et peut-être à ajouter à la crontab pour automatiser ?
D'avance merci.
GLPI 9.5.5 - OCS 2.6 Agent 2.6
Plugins : activity - dashboard - news - fields - escalade - formcreator - order - datainjection - tasklist - moreticket - ocsinventoryng - satisfaction - reports
Offline
Bonjour,
j'ai eu le même problème avec une table glpi-logs qui atteignait les 140GB !
J'ai réussi à résoudre cela en un certain nombre de fois en utilisant une ligne de commande à lancer sur le serveur à partir du répertoire Front dans to n site web GLPI.
Voici la commande : php cron.php --force PurgeLogs
Attention il faut respecter les minuscules et majuscules dans le dernier paramètre.
Avant de faire cela tu dois aller dans Configuration > Général > Purge de l'historique et modifier un des paramètres qui permettent de supprimer une partie de l'historique.
Personnellement tous les paramètres étaient à "Delete if older than 12 month" et j'ai décidé de commencer avec le paramètre "Components / Ajouter un composant" en sélectionnant la valeur "Delete if older than 11 month".
Je te conseille de ne pas modifier trop de paramètres en une fois. En supprimant un mois, le "purgelogs" prenait au minimum entre 7 et 10 heures.
Une fois que tu a sauvé les changements que tu as apporté, tu peux lancer la commande ci-dessus.
Attention ! Ce n'est pas parce que la commande "purgelogs" a tourné que tu verras une différence au niveau de la table glpi_logs.
Il faut encore lancer une optimisation de la table glpi-logs avec un outil comme Navicat. Il en existe une version spéciale pour MariaDB.
Tu peux lancer plusieurs fois la commande PHP ci-dessus puis seulement lancer l'optimisation.
En fonction de la taille de ta table glpi-logs l'optimisation peut aussi prendre plusieurs heures.
Dernière chose, pendant que tu lances la suppression des entrées dans la table glpi-logs, pense à modifier le paramètre "niveau de journalisation" dans Configuration > Général > Système à une valeur plus petite (perso j'ai mis 1) sinon GLPI va continuer à remplir la table glpi-logs pendant que tu t'acharnes à la vider.
Je te souhaite bon courage. Ca prend du temps mais dans mon GLPI j'ai réussi à diminuer la taille de la table glpi-logs de 140GB à 5MB !
Offline
Merci beaucoup pour toutes ces informations.
ça va vraiment m'aider, je n'ai pas pensé à effectuer la purge "type d'éléments par type d'éléments" c'est bien vu.
Merci pour le temps que tu as consacré pour m'aider.
Concernant l'optimisation de la base, tu as lancé quelle commande ? Car de mon côté j'ai tenté, mais j'ai eu un retour "table non compatible avec l'optimisation" ou quelque chose comme ça.
GLPI 9.5.5 - OCS 2.6 Agent 2.6
Plugins : activity - dashboard - news - fields - escalade - formcreator - order - datainjection - tasklist - moreticket - ocsinventoryng - satisfaction - reports
Offline
Oui j'ai eu le même message.
C'est parce que MariaDB ne supporte par l'optimisation de tables. La table est recréée par copie de la table originale de laquelle sont enlevés les éléments que tu as supprimés par la commande PurgeLog.
J'ai effectivement oublié de préciser que lorsque tu lances l'optimisation il faut toujours t'assurer que l'espace libre sur le disque de ton serveur est supérieur à la taille de la table glpi-logs.
Offline
Pages: 1