Page History

Surveillance du taux de fragmentation de la base

La Au fur et à mesure des insertions / suppressions d'éléments en base de données va se fragmenter au fil des insertions/suppression d'éléments, et le volume des données va devenir plus faible que le volume sur disque (dans /var/lib/mongo): c'est , l'espace de stockage peut se retrouver morcelé.

L'enchevêtrement des zones d'espace libre et des zones contenant des données est tel, qu'il devient difficile de réaffecter les zones libres pour y stocker de nouvelles données.

Le ratio espace de stockage utilisé par rapport à la taille effective des données devient plus important, c'est ce qu'on appelle la fragmentation.

Il est possible de surveiller ce taux de fragmentation et même le réduire .Nous mettons à disposition le script suivant avec la commande suivante : 

• check_mongo_fragmentation.py

Il Ce script permet d'avoir le calcul de ce taux, avec les volumes utilisés et les volumes sur disque.

Paramètres d'exécution

Sans paramètre, la commande se connecte au serveur MongoDB local.

Données retournées

La commande va fournir les informations suivantes, pour chacune des bases de données présente sur le serveur

Il se lance de la manière suivante:

check_mongo_fragmentation.py -H IP_SERVEUR --connection-method=ssh --ssh-user=shinken  --ssh-keyfile=~shinken/.ssh/id_rsa

• -H: adresse publique du serveur à vérifier
  • ou localhost si vous souhaitez vérifier le serveur sur lequel s'exécute le script
• --connection-method=ssh: à n'utiliser que pour les serveurs distants afin de créer un tunnel ssh vers le serveur et protéger les accès
• --ssh-user: utilisateur à utiliser pour les serveurs distants pour les connexions SSH
• --ssh-keyfile: clé SSH à utiliser pour les serveurs distants

Il va fournir les informations suivantes :

• Database: le nom de la base
• Disk-usage: la consommation disque de la base
• Data: le volume de données contenu dans la base
• Compression-save: espace disque économisé grâce à la compression de données ( seulement pour Wired Tiger )
• Fragmented: espace  espace non utilisé du dû à la fragmentation
  • cet Cet espace peux peut être réutilisé pour de nouvelles données, à la discrétion du moteur.
  • en En cas de compactage ou migration, la majeur majeure partie de cet espace pourra être récupéré.

Exécution sur une base avec MMapV1

Sur une base avec MMapV1 l’exécution va donner un résultat suivant :

Image Modified

• Le script va conseiller de migrer de moteur de données, de MMapV1 vers Wired Tiger, en demandant à se référer à la documentation ( MongoDB: compactage et migration de MMapV1 vers Wired Tiger voir la page MongoDB - maitriser l'espace utilisé ).
• Le script conseillera une migration de la base de données que données uniquement si le pourcentage d'espace perdu est > 50%
  • dans Dans ce cas, il conseille de se référer à la documentation ( MongoDB: compactage et migration de MMapV1 vers Wired Tiger voir la page MongoDB - maitriser l'espace utilisé ).
• Il fourni fournit l'espace perdu à cause de la fragmentation, qui pourra être récupéré lors d'une migration.
  • lL'espace sera probablement encore plus grand lors de la migration, car Wired Tiger compresse les données sur disque.

Exécution sur une base avec Wired Tiger

Sur une base avec Wired Tiger, le résultat sera le suivant :

Image Modified

• Le script ne conseillera un compactage de la base de données que si le pourcentage d'espace perdu est > 50%
  • dans Dans ce cas, il conseille de se référer à la documentation ( MongoDB: compactage et migration de MMapV1 vers Wired Tiger voir la page MongoDB - maitriser l'espace utilisé ).
• La ligne journal permet de voir la taille du journal de base de Wired Tiger, qui vaut tout le temps 200Mo.