Optimisation de ZFS ARC : plafonds, limites et paramètres à mesurer

Par défaut, ZFS utilise discrètement environ la moitié de la mémoire vive (RAM) de votre système pour son cache de lecture. Sur un serveur mal adapté, cela peut entraîner une activité de swap, des arrêts OOM (Out of Memory) ou une concurrence entre la base de données et le système de fichiers pour l’accès à la mémoire. Le réglage de l’ARC de ZFS consiste à déterminer la quantité de RAM que l’ARC est réellement autorisé à conserver, et ce à quoi vous renoncez pour fixer cette limite. Cet article explique comment l’ARC utilise la mémoire, ce qu’il faut mesurer avant de modifier quoi que ce soit, les quelques paramètres qu’il vaut la peine de modifier, ainsi que des points de départ raisonnables pour les serveurs de fichiers, les hyperviseurs, les bases de données et les cibles de sauvegarde. Pour ce qui concerne les instantanés ZFS, consultez notre guide sur les instantanés ZFS.

Mesurez l’ARC avant de procéder à tout réglage

Ne modifiez aucun paramètre réglable tant que vous ne disposez pas de chiffres de référence correspondant à une période de trafic normale. Les instantanés pris pendant les périodes creuses vous induiront en erreur. C’est généralement lors des sauvegardes nocturnes, des rapports hebdomadaires et des tâches batch que le comportement de l’ARC devient intéressant ; veillez donc à collecter des données sur plusieurs jours.

Trois outils couvrent l’essentiel de vos besoins :

• arcstat 1 fournit une vue défilante en temps réel des compteurs de succès et d’échecs, de l’activité de demande par rapport à celle de prélecture, ainsi que de la taille actuelle de l’ARC. Utilisez-le pendant les tests de charge et les fenêtres de sauvegarde.
• arc_summary affiche un instantané unique : taille et cible de l’ARC, répartition MFU/MRU, ratios de métadonnées et paramètres de réglage actifs. Exécutez arc_summary -s arc uniquement pour la section ARC.
• Les compteurs bruts se trouvent /proc/spl/kstat/zfs/arcstats sous Linux et sous la kstat.zfs.misc et vfs.zfs arborescences sysctl sous FreeBSD. Récupérez-les à partir du système de surveillance plutôt que d’analyser une sortie formatée.

Les compteurs à enregistrer avant toute modification :

Il y a deux erreurs courantes à ce sujet. Surveillez la mémoire disponible, pas la mémoire libre ; Linux signale sans problème un faible niveau de RAM libre comme un état stable, ce qui n’est pas un problème en soi. Le signal qui importe, c’est une mémoire disponible proche de zéro associée à une activité de swap soutenue (le guide d’introduction à la gestion de la mémoire sous Linux explique pourquoi). Et considérez le taux de réussite comme une tendance, pas comme un objectif. Un taux de réussite de 99 % sur une machine qui utilise le swap est un échec de l’optimisation, pas une réussite.

Les quatre paramètres ARC qui comptent

La plupart des réglages en production se résument à quatre paramètres. Adaptez le réglage à la pression que vous avez réellement mesurée lors de la ligne de base. L'activité d'échange indique zfs_arc_max. La récupération des données perdues qui effacent sans cesse un cache actif indique zfs_arc_min. Un parcours lent des répertoires indique que la limite de métadonnées est atteinte.

Commencez par le plus petit ajustement permettant de remédier à la pression que vous constatez. zfs_arc_max, la limite supérieure appropriée dépend de la charge de travail (abordée dans la section suivante). Pour zfs_arc_min, un seuil minimal compris entre 25 % et 50 % de zfs_arc_max constitue un point de départ raisonnable, si tant est que vous en ayez besoin. Pour les métadonnées, les paramètres par défaut récents d’OpenZFS leur attribuent déjà 75 % de l’ARC via zfs_arc_meta_limit_percent, ce qui est généreux pour la plupart des charges de travail ; ne modifiez ce paramètre que lorsque des pertes de métadonnées sont clairement visibles dans arcstat.

Application des modifications sous Linux et FreeBSD

Sous Linux, testez une modification à l’exécution en écrivant dans le fichier de paramètres sysfs. Aucun redémarrage n’est nécessaire :

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

Cela règle zfs_arc_max immédiatement à 16 Gio. Pour que la modification soit conservée après un redémarrage, ajoutez-la à /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

Sous FreeBSD, les modifications à l’exécution utilisent sysctl:

sysctl vfs.zfs.arc_max=17179869184

Pour conserver la même valeur dans /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Modifiez un paramètre à la fois, par petits paliers d’environ 10 % de la mémoire vive totale. Surveillez la fenêtre des problèmes. Ne conservez la modification que si l’espace d’échange reste à zéro et que la latence est stable. Ne rendez la modification permanente qu’après la réussite du test à l’exécution.

Dimensionnement de l’ARC en fonction de la charge de travail

La mémoire vive totale n’est pas le bon point de départ. Le dimensionnement de l’ARC doit suivre la composition de la charge de travail sur le serveur.

Un hôte de machines virtuelles doit partager la mémoire avec ses invités ; un plafond de 30 % à 40 % constitue donc une valeur par défaut sûre, et 50 % est déjà trop élevé sur la plupart des configurations. Les bases de données telles que PostgreSQL et MySQL gèrent leurs propres caches tampons ; il faut donc réserver la mémoire au moteur en premier lieu et laisser à l’ARC ce qui reste. Les cibles de sauvegarde en bénéficient primarycache=metadata car les données lues ne sont que rarement réutilisées, et vous ne souhaitez pas qu’une sauvegarde nocturne parcoure l’ensemble du pool et vide le reste du cache au fur et à mesure. Quelle que soit la charge de travail, une activité d’échange (swap) alors que l’ARC est bloqué à zfs_arc_max indique que la limite est trop élevée ; cette règle reste inchangée.

Diagnostiquer les problèmes et savoir quand s'arrêter

Un ARC sous-dimensionné se traduit par un nombre élevé d’IOPS en lecture, de faibles taux de réussite des requêtes et une navigation lente dans les répertoires, alors même que le système dispose encore de mémoire vive libre. Un ARC surdimensionné est moins évident. Le taux de réussite semble correct, mais la machine commence à recourir au swap, les moyennes de charge grimpent, les processus se bloquent en D lorsque le noyau récupère des pages de l’ARC à la demande, et dans le pire des cas, le « OOM killer » commence à choisir ses victimes. Le cache semble en bon état, mais le serveur fonctionne très mal.

La pression liée aux métadonnées se manifeste lorsque demand_metadata_bytes est nettement supérieure à demand_data_bytes dans arc_summary. C’est à ce moment-là que les métadonnées se disputent l’espace avec les données, et qu’il vaut mieux augmenter la limite en pourcentage des métadonnées.

Faites correspondre ce que vous observez au premier paramètre à vérifier :

Le L2ARC n’est pas gratuit. L’index des entrées L2ARC réside dans l’ARC primaire, et si cette surcharge dépasse environ un tiers de la capacité totale de l’ARC, le cache secondaire fait plus de mal que de bien. N’utilisez le L2ARC que lorsque l’ensemble de travail est plus volumineux que la RAM mais tient encore sur un périphérique NVMe rapide, et uniquement lorsque le taux de réussite de l’ARC primaire est déjà satisfaisant.

Le moment idéal pour cesser l’optimisation est lorsque la latence est stable, que l’utilisation de la mémoire de pagination reste à zéro pendant la même période de forte activité qui a causé le problème initial, et que de nouvelles modifications n’apportent plus aucune amélioration. Un taux de réussite élevé ne signifie rien si le serveur utilise la mémoire de pagination. Passé ce stade, cessez d’ajuster les paramètres et ne les réexaminez que si le même problème réapparaît avec la même charge de travail.

Si vous avez besoin d’un serveur disposant d’une marge de RAM suffisante pour faire fonctionner correctement ZFS sans entrer en concurrence avec vos machines virtuelles ou vos bases de données pour la mémoire (il est utile de lire d’abord cet article pour savoir de combien de RAM vous avez réellement besoin), jetez un œil aux serveurs dédiés FDC.