FAQ MongoDBConsultez toutes les FAQ

Les fichiers de données dans votre répertoire de données, qui est le répertoire /data/db dans les configurations par défaut, pourraient être plus grands que l'ensemble de données inséré dans la base de données. Considérez les causes possibles suivantes :

MongoDB préalloue ses fichiers de données afin d'éviter la fragmentation, et de ce fait la taille de ces fichiers ne reflète pas nécessairement la taille de vos données.

L'option storage.mmapv1.smallFiles permettra de réduire la taille de ces fichiers, ce qui peut être utile si vous avez beaucoup de petites bases de données sur le disque.

Si cette mongod est un membre d'un replica set, le répertoire de données inclut le fichier oplog.rs, qui est une collection de taille limitée préallouée dans la base de données local.

L'allocation par défaut est d'environ 5 % de l'espace disque sur les installations 64 bits. Dans la plupart des cas, vous ne devriez pas avoir besoin de redimensionner l'oplog. Voir Dimensionnement de l'oplog pour plus d'informations.

Le répertoire de données contient les fichiers journal, qui stockent les opérations d'écriture sur le disque avant que MongoDB les applique aux bases de données. Voir Mécanique de journalisation.

MongoDB maintient des listes d'enregistrements vides dans les fichiers de données lorsqu'elle supprime des documents et des collections. MongoDB peut réutiliser cet espace, mais ne cédera pas, par défaut, cet espace au système d'exploitation.

Pour permettre à MongoDB de réutiliser plus efficacement l'espace, vous pouvez défragmenter vos données. Pour ce faire, utilisez la commande compact, qui nécessite jusqu'à 2 gigaoctets d'espace supplémentaire sur le disque pour fonctionner. N'utilisez pas compact si vous disposez de très peu d'espace disque. Pour plus d'informations sur son comportement et d'autres considérations, voir compact.

compact ne fait que supprimer la fragmentation de fichiers de données MongoDB au sein d'une collection et ne retourne pas d'espace disque au système d'exploitation. Pour récupérer de l'espace disque pour le système d'exploitation, voir Comment puis-je récupérer l'espace disque ?.

Ce qui suit fournit quelques options à considérer lors de la récupération de l'espace disque.

	Vous ne devez pas récupérer de l'espace disque pour que MongoDB réutilise l'espace libéré. Voir Enregistrements vides pour plus d'informations sur la réutilisation de l'espace libéré.

Vous pouvez utiliser repairDatabase sur une base de données pour reconstruire la base de données, défragmentant le stockage associé dans le processus.

repairDatabase nécessite de l'espace disque libre égal à la taille de votre ensemble de données actuel plus 2 gigaoctets. Si le volume qui stocke dbpath manque d'espace suffisant, vous pouvez monter un volume séparé et l'utiliser pour la réparation. Pour plus d'informations et considérations supplémentaires, voir repairDatabase.

	Ne pas utiliser repairDatabase si vous disposez de très peu d'espace disque. repairDatabase bloquera toutes les autres opérations et peut prendre beaucoup de temps.

Pour un membre secondaire d'un replica set, vous pouvez effectuer une resynchronisation de membre par : l'arrêt de la resynchronisation de l'élément secondaire, la suppression de tous les données et sous-répertoires du répertoire des données du membre et redémarrage.

Pour plus de détails, voir Resynchroniser un membre de replica set.

Le working set représente le volume total de données que l'application utilise dans le cadre d'un fonctionnement normal. Souvent, cela est un sous-ensemble de la taille totale de données, mais la taille spécifique du working set dépend de l'utilisation réelle de la base de données d'un moment à l'autre.

Si vous exécutez une requête qui nécessite que MongoDB parcoure tous les documents d'une collection, l'ensemble de travail sera élargi pour inclure tous les documents. Selon la taille de la mémoire physique, cela peut causer l'exclusion de la pagination des documents du working set, ou leur suppression de la mémoire physique par le système d'exploitation. La prochaine fois que MongoDB aura besoin d'accéder à ces documents, MongoDB peut encourir un défaut grave de pagination.

Pour de meilleures performances, la majorité de votre ensemble actif doit pouvoir être stocké dans la RAM.

Avec le moteur de stockage MMAPv1, les défauts de page peuvent se produire lorsque MongoDB lit ou écrit des données dans des parties de ses fichiers de données ne se trouvant pas actuellement dans la mémoire physique. En revanche, les défauts de page des systèmes d'exploitation se produisent lorsque la mémoire physique est épuisée et des pages se trouvant dans la mémoire physique sont permutées sur le disque.

S'il existe de la mémoire libre, alors le système d'exploitation peut trouver la page sur le disque et la charger directement dans la mémoire. Cependant, s'il n'y a pas de mémoire libre, le système d'exploitation doit :

• trouver dans la mémoire une page qui est périmée ou n'est plus nécessaire et écrire la page sur le disque ;
• lire la page demandée à partir du disque et la charger dans la mémoire.
  

Les défauts de page se produisent lorsque MongoDB, avec le moteur de stockage MMAP, a besoin d'accéder à des données qui ne sont pas actuellement dans la mémoire active. Un défaut de page « grave » survient dans des situations où MongoDB doit accéder à un disque pour accéder aux données. Un défaut de page « léger », en revanche, ne fait que déplacer les pages d'une liste à l'autre en mémoire, par exemple, à partir de la cache de fichiers du système d'exploitation.

Voir Défauts de page pour plus d'informations.