ZFS mange toute votre RAM : ce que l'ARC fait vraiment, et quand s'en inquiéter

Vous mettez ZFS en place, tout fonctionne, puis vous regardez la consommation mémoire : 90 % occupés, sur une machine qui ne fait pourtant pas grand-chose. Le réflexe est de chercher une fuite. Il n'y en a pas — mais l'explication rassurante habituelle, « c'est juste du cache, ignorez-le », est incomplète. Sur un hyperviseur, ce cache peut réellement vous causer des ennuis.

L'ARC, en une minute

L'ARC (Adaptive Replacement Cache) est le cache de lecture de ZFS. Il garde en mémoire les blocs les plus utiles, selon deux critères combinés : ce qui a été lu récemment et ce qui est lu fréquemment. Cette double logique est ce qui le distingue d'un cache classique : un gros balayage séquentiel ne suffit pas à évincer les données réellement chaudes.

Par défaut, il vise environ la moitié de la mémoire de la machine, et il rend cette mémoire quand une application en réclame. De la RAM inutilisée ne rend service à personne : la remplir de cache est un comportement souhaitable, pas un défaut.

Sur un serveur de fichiers dédié, il n'y a donc rien à faire. Laissez-le travailler.

Pourquoi c'est différent sur un hyperviseur

Le raisonnement « l'ARC rend la mémoire à la demande » est exact, mais il escamote une variable décisive : la vitesse.

Un hyperviseur ne demande pas la mémoire progressivement. Quand une VM démarre, elle réclame plusieurs gigaoctets d'un seul coup et immédiatement. L'ARC doit alors libérer — ce qui prend du temps, d'autant plus qu'il est volumineux et que la mémoire est fragmentée. Si l'allocation échoue avant la fin de la libération, le démarrage est refusé.

Le symptôme est déroutant : une VM refuse de démarrer alors que la machine semble avoir de la marge, et le problème disparaît quelques minutes plus tard. Ce n'est pas un manque de mémoire, c'est un problème de latence de restitution.

Comment dimensionner sans casser les performances

Le raisonnement est simple : partez de la mémoire totale, retirez ce que les VM et conteneurs peuvent réclamer simultanément au pire, gardez une marge pour l'hôte, et donnez le reste à l'ARC.

Deux erreurs symétriques à éviter :

• Plafonner trop bas « par sécurité ». Le taux de succès du cache s'effondre, chaque lecture repart sur les disques, et les performances chutent de façon très visible. Un ARC à quelques centaines de mégaoctets sur un hyperviseur actif est contre-productif.
• Ne rien plafonner du tout sur une machine où les VM démarrent et s'arrêtent régulièrement. Vous vous exposez au problème d'allocation décrit plus haut, de façon intermittente et difficile à diagnostiquer.

Le réglage se vérifie, il ne se devine pas. Les statistiques du noyau exposent la taille courante de l'ARC, sa cible, et surtout le taux de succès du cache. C'est cette dernière valeur qui doit guider l'ajustement : tant qu'elle reste élevée, le plafond est correct. Si elle s'effondre après un serrage, remontez.

Le mythe du gigaoctet par téraoctet

« ZFS exige 1 Go de RAM par téraoctet de stockage » revient constamment. C'est faux dans le cas général, et cette croyance dissuade des installations parfaitement viables.

Cette règle vient de la déduplication. Celle-ci maintient une table d'empreintes qui doit rester en mémoire, et dont la taille croît avec le volume de données. Quand elle ne tient plus en RAM, les performances s'effondrent brutalement.

Or la déduplication est déconseillée dans la quasi-totalité des usages : son coût est permanent, ses gains sont marginaux sauf sur des données massivement redondantes, et la compression — activée par défaut, quasi gratuite en CPU — apporte le plus souvent un meilleur résultat.

Sans déduplication, ZFS fonctionne correctement avec quelques gigaoctets de RAM sur plusieurs téraoctets de données. Davantage de mémoire améliore les lectures ; ce n'est pas un prérequis.

Le cache SSD : à envisager en dernier

Puisque la RAM manque, autant ajouter un SSD comme cache de second niveau ? C'est souvent une fausse bonne idée.

Ce cache a besoin d'un index maintenu en mémoire vive. Il consomme donc de la RAM — précisément la ressource qui manquait — et cette RAM n'est plus disponible pour l'ARC, qui est des ordres de grandeur plus rapide qu'un SSD. Sur une machine déjà juste en mémoire, l'ajout dégrade fréquemment les performances au lieu de les améliorer.

L'ordre correct est : saturer la RAM d'abord, mesurer le taux de succès de l'ARC ensuite, et n'envisager un cache SSD que si le jeu de données actif dépasse durablement la mémoire installable.

À retenir

Une RAM à 90 % sur un serveur ZFS n'est pas un problème : c'est le fonctionnement attendu. Sur un hyperviseur, en revanche, la question n'est pas « combien l'ARC consomme » mais « à quelle vitesse peut-il rendre ». Plafonnez en fonction de vos pics d'allocation, vérifiez avec le taux de succès du cache, et oubliez la règle du gigaoctet par téraoctet.