You are not logged in.
Pages: 1
Bonjour,
J'ai la version 0.83.1 de GLPI qui roule depuis près de 3 ans. Nous avons eu quelques difficultés en cours de route, mais toujours capable de les régler. Mon parc est constitué de près de 5000 machines. Avant je ne m'occupais pas de l'historique de chaque poste, mais je me suis fait dire que depuis le début nous avions le problèmes suivants :
Plus rien ne s'affiche dans l'onglet "Historique" des postes. Quand je vais en phpmyadmin, je regarde la table "glpi_logs" et une erreur rouge apparaît.
Je n'ai plus le message, car je n'ai pas pensé le prendre en note. Pour corriger le problème, je dois faire un truncate sur la table pour la vider complètement, ce qui en bout de ligne me donne rien car je n'ai plus d'entré dans l'historique. Par la suite l'historique remarche et quand elle est pleine(car c'est ce que je suppose), même problème.
Donc je me demande s'il y a un certain "log level" que nous pouvions mettre pour ne pas tout avoir l'historque (ex.: ne plus avoir les historiques de mise à jour Windows).
Sinon, quel serait la solution?
Il faut dire que je ne m'occupe pas de côté serveur et paramétrisation de ce dernier. Je ne fais que le pilotage de l'application. Je ne connais pas les spécifications serveur qui a été utilisé. Je ne crois pas que ce soit un problème d'espace du serveur, car nous sommes capable d'importer d'autre ordinateur, c'est vraiment juste relié à l'historique des postes.
Merci!
Last edited by Nelson24 (2013-02-19 00:31:27)
Glpi : 0.84.7
Mysql : 5.5.38
OcsInventoryNG : 2.1.2
Serveur : 5.5.38-0ubuntu0.14.04.1 - (Ubuntu)
Offline
Je pense que ta table dois crasher, donc faut la réparer au lieu de la vider.
Si ça se crashe, c'est que ton serveur MySQL est un peu lent au niveau des disques (ou limité en IO par le système de VM si c'est en VM)
Offline
une fois la table réparée, je vous conseille de jeter un coup d’œil sur ce plugin : https://forge.indepnet.net/projects/purgelogs
Offline
Dois-je faire la réparation immédiatement, ou bien je dois attendre que la table crashe de nouveau? De plus si on parle que le serveur est lent au niveau des disques, ce serai la BD au complet qui crashe non pas juste la table des LOG ??
Je vais me renseigné si c'est un VM. De plus, peut-on limité la grosseur de la BD à X gig sur le serveur et aussi peut-on limiter la grosseur des tables de la BD a X gig une fois quel est créé. Car je me demande si ce n'est pas juste la table qui a atteint sa limite?
Merci pour le plugin, ceci va nous aider beaucoup!
Glpi : 0.84.7
Mysql : 5.5.38
OcsInventoryNG : 2.1.2
Serveur : 5.5.38-0ubuntu0.14.04.1 - (Ubuntu)
Offline
avant de faire quoique ce soit, une réparation et une optimisation de la base s'imposent
Offline
J'ai regardé plus en détail les entrées dans les tables et j'ai eu des bugs avec certains postes lors de leur importation via OCS. Il arrivait que les logiciels se désinstallais et se réinstallais à tous les 5 minutes ce qui faisait exploser totalement la table avec 50 millions d'entrées.
J'ai flushé les postes et réimporter et tout allait bien. Sauf qu'un autre problème survenait, les tables liées au logiciels avait plus de 2 millions d'entrées. Après avoir fait plusieurs tests, je peux vider les tables reliés au logiciels et versions de logiciels et attendre que les postes se réimporte d'eux même ce qui me donne des tables clean.
Donc à la toute fin, ma table glpi_logs ne contient que 5 millions d'entrées et les logiciels 700 000 au lieux de 2 millions.
Par la suite, je vais mettre en place le purge_logs ce qui va maintenir une quantité normal d'entrée dans la table.
Merci à tous, on peux fermer le sujet
Glpi : 0.84.7
Mysql : 5.5.38
OcsInventoryNG : 2.1.2
Serveur : 5.5.38-0ubuntu0.14.04.1 - (Ubuntu)
Offline
Pages: 1