[GLPI/BD]: Probleme de taille du fichier glpi_logs

J2C99 · 2024-02-02 12:17:02

Bonjour

Nous avons identifié, durant la migration GLPI 9.5 => 10, un probleme sur la volumétrie de la table glpi_logs.
Etant donné que notre instance a un certain vécu, la table contient un nombre important d'enregistrements (+80 M).
Régulièrement des suppressions sont effectuées afin de réduire ce nombre, et limiter ainsi la taille des dumps de la base de donnée.

Tout cela fonctionnait , mais les tests de migration ont soulevé un problème.

L'outil console effectue un check de cohérence du modèle de donnée pour identifier les écarts avant migration.
Afin de réduire ces écarts, des modifications sont apportées à la base et particulèrement à la table 'glpi_logs' (ex , modification de champs / recréation d'index).
Lorsque j'applique ces modifications à glpi_logs, j'ai une erreur de type table Full apres un certain temps.
Cela se produit, quand l'espace disponible sur le filesystem atteint 0 durant l'application des modifs sur cette table.

Apres analyse,il s'avère que la suppression d'enregistrements (DELETE FROM ... ) dans une tables ne modifient pas la taille du fichier .idb correspondant à la table.

C'est une caractéristique d'INNODB, les fichiers .idb ne peuvent que croitre.

Toute opération de type ALTER TABLE, OPTIMIZE, .. et autre, entraine une copie temporaire de la table pour appliquer ces modifs, suivi d'une permutation avec celle-ci
Cela implique donc d'avoir un espace disque disponible supérieur au fichier de la table glpi_logs
Quand l'instance GLPI a un certain historique, on parle de plusieurs dizaines de Go.

Eric26 · 2024-02-02 12:54:49

Bonjour,

Cette expansion de la table glpi_logs est étonnante. J'utilise GLPI depuis 2006 en faisant évoluer toutes les versions jusqu'à la dernière actuelle et je ne remarque pas ce phénomène.
Le fichier de ma table glpi_logs ne fait "que" 266 Mo et pourtant GLPI est utilisé à quasi 100% de ses fonctionnalités (ticketting, inventaires matériels, FAQ, etc...) + les plugins.

HervéM · 2024-02-02 13:20:01

Bonjour,

Voici quelques suggestions qui pourraient vous être utiles pour résoudre l'erreur "table full" lors de la migration de GLPI 9.5 vers 10 :

- Augmentez l'espace disque disponible sur le serveur GLPI ou déplacez la base de données vers un serveur avec plus d'espace.
- Optimisez la table glpi_logs en supprimant les enregistrements inutiles, en archivant les anciens logs et en compactant la table.
- Avant d'effectuer la migration en production, testez-la sur un environnement de test.

J2C99 · 2024-02-02 15:39:30

Bonjour,

Oui, Hervé
ceci est exactement ce qui est fait
Actuellement la méthode trouvée pour réduire la taille de la table glpi_logs est:
Sauvegarde ( dump de cette table avec mysqldump ), suivi d'un reload de la table.
Un 'OPTIMIZE TABLE' est aussi possible,la table temporaire sera créé en local, cela pouvant poser probleme.

En effectuant ceci , je me retrouve avec une table contenant 55M d'enregistrements pour 12 Go,
Vu qu'un enregistrement ne peut dépasser 1Ko, la taille n'est pas trop déconnant.

SELECT table_schema AS DB_NAME, TABLE_NAME, (DATA_LENGTH+INDEX_LENGTH)/1024/1024/1024 AS TABLE_SIZE_in_GO
FROM information_schema.TABLES
WHERE TABLE_NAME='glpi_logs';
+---------------+--------------+--------------------+
| DB_NAME | TABLE_NAME | TABLE_SIZE_in_GO |
+---------------+--------------+--------------------+
| GLPI_10_0_11 | glpi_logs | 12.527252197266 |
+---------------+--------------+--------------------+

Pour Eric26,
Combien contient d'enregistements dans ta table glpi_logs ?
Je trouve que 226 Mo est relativement faible.
As tu effectuer des réglages pour restreindre la remontée de logs ?
As tu activé innodb_file_per_table ?
MariaDB [(none)]> show variables like "innodb_file_per_table";

Last edited by J2C99 (2024-02-02 15:48:57)

J2C99 · 2024-02-02 16:23:04

Une possibilité serait d'activer la compression au niveau de la table => https://mariadb.com/kb/en/innodb-compressed-row-format/
ALTER TABLE glpi_logs ROW_FORMAT=COMPRESSED;

Cela réduit la volumétrie de 50% (donc je passe à 6Go) .
je regarde les impacts.

Last edited by J2C99 (2024-02-02 16:28:17)

J2C99 · 2024-03-14 10:41:29

Apres un mois de run sur la production, pas d'impact identifié .
(Par contre la génération de la table a été assez long chez moi: 2h, mla taille est passé de 12 à 6 Go)

Le mode opératoire peut etre le suivant
(Utilise une table intermédaire avec un filtrage sur les données initiales)

CREATE TABLE test (
   id INT NOT NULL AUTO_INCREMENT,
   PRIMARY KEY(id),
   KEY `date_mod` (`date_mod`),
   KEY `itemtype_link` (`itemtype_link`),
   KEY `item` (`itemtype`,`items_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=COMPRESSED;

SELECT itemtype,
items_id,
   itemtype_link,
   linked_action,
   user_name,
   date_mod,
   id_search_option,
   old_value,
   new_value
FROM glpi_logs
WHERE id > 47072868 ;

RENAME TABLE test TO glpi_logs;
DROP TABLE glpi_logs_bck;

Last edited by J2C99 (2024-03-14 10:43:39)

Forum GLPI-Project

Announcement

#1 2024-02-02 12:17:02

[GLPI/BD]: Probleme de taille du fichier glpi_logs

#2 2024-02-02 12:54:49

Re: [GLPI/BD]: Probleme de taille du fichier glpi_logs

#3 2024-02-02 13:20:01

Re: [GLPI/BD]: Probleme de taille du fichier glpi_logs

#4 2024-02-02 15:39:30

Re: [GLPI/BD]: Probleme de taille du fichier glpi_logs

#5 2024-02-02 16:23:04

Re: [GLPI/BD]: Probleme de taille du fichier glpi_logs

#6 2024-03-14 10:41:29

Re: [GLPI/BD]: Probleme de taille du fichier glpi_logs

Board footer