Bien régler MongoDB pour éviter la saturation de disque

Cet article a été publié il y a 9 ans 7 mois 21 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Petite surprise pendant mes tests pour savoir qui de PHP 5.5, 5.6, ou HHVM aura ma préférence, le log d’HHVM m’a sorti une erreur après son installation sur le fait que je n’avais plus de place. Et il s’avère que MongoDB, que je vous ai fait découvrir il y a quelques temps maintenant (là, là, puis là et encore là), peut être très gourmand. Alors on va contenir un peu tout ça.

En effet, lors du premier affichage de la page d’accueil de la copie du blog, que j’ai trouvé très lente, même sur ma connexion, j’ai découvert ça dans le log d’HHVM :

Hein ? bon, sans non plus refaire toutes les manips que je vous conseille dans cet article, j’ai déjà nettoyé le cache d’APT, car il m’a installé pas mal de paquets en plus d’HHVM. 500Mo de gagné, mais toujours 94% d’occupation. Donc un petit coup de ncdu, et tiens, le dossier /var/lib/mongodb/journal prend plus de 3Go à lui tout seul, avec donc trois fichiers d’1Go chacun. Euh, oui, sauf que ma base de données n’a que 441 films dedans, pas de quoi retourner un disque dur, même virtuel, normalement.

Après un tour sur la documentation, il s’avère que MongoDB est très généreux sur ces fichiers de pré-allocation. Fort heureusement, il est possible de réduire la taille de ces fichiers. On commence par couper temporairement le serveur MongoDB :

Ensuite, on supprime ces fichiers proprement :

Avant de relancer MongoDB, on édite son fichier de configuration /etc/mongodb.conf pour y ajouter, à la fin, la simple ligne suivante :

Dès lors, les fichiers de pré-allocation ne pèseront plus que 128Mo au lieu d’1Go. Autant dire que ça fait pas mal de place de gagnée. Il n’y a plus alors qu’à démarrer le serveur :

Après quelques secondes, si on regarde, les fichiers sont recréés, mais avec la nouvelle taille :

Attention toutefois, car sur de grosses bases de données, MongoDB pourrait être poussé à créer plus de fichiers du coup, ce qui entraînerait des chutes de performance. Il faudra donc faire un choix, la performance n’étant pas ma priorité pour l’instant.

Concernant HHVM, j’aurais l’occasion d’en reparler dans quelques temps (peut-être plus tôt que prévu). Juste pour dire que les louanges sont méritées.