ZFS a un super-pouvoir : il transforme la RAM en moins d’accès disque, moins d’allers-retours et moins de regrets. L’ARC (Adaptive Replacement Cache) est la raison pour laquelle un sous-système disque médiocre peut sembler sous caféine. C’est aussi la raison pour laquelle un serveur parfaitement sain peut soudain donner l’impression d’avancer dans de la colle — parce que l’ARC « gagne » une bataille de mémoire qu’il ne devrait pas livrer.
C’est la partie que la plupart des guides de tuning zappent : l’ARC ne vit pas seul. Il entre en concurrence avec le cache de pages du noyau, les tas des applications, le ballooning VM, les limites des conteneurs, les métadonnées du système de fichiers et le « bazar » dont l’OS a besoin pour rester en vie. Quand l’ARC devient trop grand (ou se réduit trop lentement), il peut provoquer du swap, des blocages de reclaim direct, des pics de latence et des pannes en cascade qui vous font vous demander si vos graphiques de monitoring ne sont pas une œuvre d’art performance.
Ce qu’est l’ARC (et ce qu’il n’est pas)
L’ARC est le cache en mémoire de ZFS pour les données de fichiers et les métadonnées. Ce n’est pas « juste un cache de lecture » dans le sens simpliste. C’est un cache multi-listes (MRU/MFU plus des listes « fantômes ») conçu pour s’adapter aux charges qui oscillent entre lectures en flux et relectures, et entre accès orientés métadonnées et orientés données.
L’ARC joue aussi un rôle dans la façon dont ZFS évite de toucher le disque pour les métadonnées en permanence — pensez blocs indirects, dnodes, parcours d’arborescence et la chaîne générale « où est vraiment mon fichier ? » Si vous avez déjà vu un pool avec beaucoup d’IOPS bruts mais une charge qui rampe, c’est souvent la latence des métadonnées, pas le débit des données.
Ce que l’ARC n’est pas : ce n’est pas le cache de pages Linux (même s’il est en concurrence avec lui), ce n’est pas un substitut à la mémoire d’une application, et ce n’est pas un levier magique « donnez-moi toute la RAM » qui rendrait toutes les charges plus rapides. Le rôle de l’ARC est de réduire les E/S disque. Si votre goulet d’étranglement n’est pas les E/S disque, l’ARC peut devenir le presse-papier le plus cher du monde.
Blague en une phrase #1 : l’ARC, c’est comme un stagiaire avec une armoire de classement énorme — utile jusqu’à ce qu’il la mette dans le seul couloir et bloque la sortie de secours.
ARC, données sales et pourquoi les charges d’écriture compliquent l’affaire
Le comportement d’écriture dans ZFS est plus gouverné par le mécanisme des transaction groups (TXG) et les limites de données sales que par le dimensionnement de l’ARC, mais la RAM reste un champ de bataille partagé. Les gros écrivains peuvent pousser des pages sales, le comportement du ZIL/SLOG et le writeback asynchrone dans une zone de contention mémoire.
Un ARC surdimensionné n’« absorbe » pas directement les données sales, mais il réduit la marge pour tout le reste, et cela change la façon dont le noyau se comporte sous pression. Quand la machine manque de mémoire, le writeback peut devenir explosif, la latence devient en pics, et vous vous retrouvez à déboguer le « stockage » alors que la cause racine est le reclaim mémoire.
Pourquoi trop d’ARC nuit : les mécanismes réels
Soyons francs : « plus de cache est toujours mieux » n’est vrai que si vous avez une RAM infinie et aucun autre consommateur. Les systèmes de production ne sont pas des romans de fantaisie. Ils ont des budgets.
Mécanisme 1 : ARC vs. le cache du noyau et le comportement de reclaim
Sur Linux, le cache de pages du noyau effectue aussi du caching. Avec ZFS, vous pouvez vous retrouver avec deux caches : l’ARC (à l’intérieur de ZFS) et le page cache (pour des éléments comme les binaires, bibliothèques, fichiers mmap hors contexte ZFS, et parfois même des effets adjacents selon l’interaction de votre charge). Si l’ARC revendique trop de RAM, le noyau peut reclaimer agressivement ailleurs, entraînant des blocages.
Symptômes : du temps CPU passé dans le reclaim du noyau, une charge système élevée sans réelle utilisation CPU, et des processus coincés en sommeil non interrompable (D state). Les utilisateurs interprètent cela comme « le disque est lent » parce que tout attend le reclaim mémoire qui ressemble à de l’attente E/S.
Mécanisme 2 : Thrash de swap : la taxe de performance que vous payez en continu
Le swap n’est pas mal en soi ; le swap incontrôlé l’est. Une machine qui commence à swapper parce que l’ARC est trop grand peut entrer dans une boucle de rétroaction :
- La pression mémoire augmente → le noyau swappe des pages d’application froides.
- La latence augmente → les applications piétinent et timeoutent.
- Les travaux relancés augmentent → plus d’allocations mémoire, plus de pression.
- L’ARC peut se réduire, mais pas toujours assez vite, ni de façon prévisible pour vos SLO.
Si vous n’avez jamais vu de swap thrash en production, vous n’avez pas vécu. C’est comme regarder un chariot élévateur faire du ballet : techniquement possible, émotionnellement perturbant.
Mécanisme 3 : VMs et conteneurs : l’ARC peut affamer vos invités
Sur les hôtes de virtualisation (Proxmox, bhyve, KVM sur ZoL), l’ARC n’est pas « gratuit ». L’hyperviseur et les invités ont aussi besoin de mémoire. Le ballooning et l’overcommit aggravent cela, parce que l’hôte peut sembler correct jusqu’à ce qu’il ne le soit plus, moment où l’hôte commence à reclaim et swapper pendant que les invités crient aussi pour la mémoire. Un ARC surdimensionné transforme un overcommit gérable en incident au niveau de l’hôte.
Mécanisme 4 : Dominance des métadonnées : l’ARC grandit avec ce que vous touchez
L’ARC n’est pas uniformément « données ». Certaines charges sont riches en métadonnées : des millions de petits fichiers, des conteneurs décompressant des couches, des systèmes CI, des gestionnaires de paquets, des patterns type maildir, des sauvegardes parcourant des arbres. L’ARC se remplira volontiers de métadonnées qui accélèrent ces parcours — jusqu’à ce qu’il évince la mémoire dont votre base de données ou votre JVM avait besoin pour éviter des tempêtes de garbage collection.
Mécanisme 5 : Mal interpréter la « mémoire libre » conduit à de mauvaises décisions
ZFS aime la mémoire. Linux aime aussi utiliser la mémoire. Avoir peu de mémoire « libre » est normal. La question est de savoir si le système peut reclaimer la mémoire rapidement sous demande sans swap ni blocage. L’ARC peut être réglé pour être un bon citoyen — ou agir comme si il payait le loyer et que tout le monde sous-louait.
Faits et contexte historique qui changent votre tuning
- L’ARC a été conçu pour surpasser le LRU classique en s’adaptant entre « utilisé récemment » et « utilisé fréquemment » ; ce n’est pas un cache stupide que l’on peut raisonner avec un seul ratio.
- L’écosystème d’origine de ZFS attendait de grosses machines avec beaucoup de RAM. Les premières déploiements de ZFS vivaient souvent sur des systèmes où « beaucoup de mémoire » était la norme, et les conseils de tuning reflétaient cette culture.
- Sur Linux, ZFS vit en dehors du modèle de cache VFS natif de façons importantes ; c’est pourquoi les interactions ARC/page-cache et le comportement de reclaim sont centraux pour la performance.
- L2ARC existe parce que les disques étaient lents et la RAM chère. Aujourd’hui, le NVMe change la donne : parfois « ajouter de la RAM » bat « ajouter un L2ARC », et parfois aucun des deux n’importe si vous êtes CPU-limité.
- L’ARC contient à la fois données et métadonnées ; dans les charges riches en métadonnées, un ARC modeste peut surpasser un ARC énorme qui provoque du swap.
- L’ARC a historiquement eu des douleurs de tuning autour du comportement de shrink sous pression. Des améliorations ont eu lieu au fil du temps, mais vous ne devez pas supposer qu’il rendra toujours la mémoire exactement quand vous en aurez besoin.
- La déduplication dans ZFS est célèbre pour sa faim mémoire parce que le DDT (dedup table) veut de la RAM ; les gens confondent « ZFS a besoin de RAM » avec « donnez tout à l’ARC », ce qui est la mauvaise leçon.
- La virtualisation a changé la conversation par défaut sur l’ARC. En 2010, un « serveur de stockage » était souvent un serveur dédié au stockage. En 2025, c’est souvent un serveur de stockage qui héberge aussi une petite ville de VMs.
- La compression a rendu le caching plus précieux parce que des blocs compressés signifient plus de données logiques par octet d’ARC — mais cela veut aussi dire que le CPU peut devenir la limite avant le stockage.
Trois histoires du monde de l’entreprise depuis le terrain
Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse
Le ticket a commencé innocemment : « pics de latence API tous les jours vers 10:00 ». C’était un hôte VM avec des volumes backés par ZFS pour plusieurs services. L’on-call a vu des disques à 20 % d’utilisation et a supposé « pas le stockage ». Les graphiques montraient la mémoire « principalement utilisée », mais c’est normal sur Linux, non ?
Puis quelqu’un a remarqué le graphe de swap : une pente lente ascendante commençant à 09:40, atteignant une falaise vers 10:05. À 10:10, les pods API redémarraient à cause de timeouts. La moyenne de charge de l’hôte était élevée, mais le CPU ne l’était pas. C’est l’odeur des tempêtes de reclaim : des tâches qui attendent la mémoire et les E/S, sans faire de travail.
L’hypothèse erronée était subtile : « l’ARC va se réduire quand il faudra ». Il s’est réduit — éventuellement. Mais « éventuellement » se mesurait en minutes, et les minutes sont une éternité pour des APIs client-facing. Le déclencheur immédiat était un job programmé qui parcourait un très grand arbre de petits fichiers (buffet de métadonnées), gonflant l’ARC en métadonnées juste au moment où les JVM voulaient étendre leur heap.
Le correctif n’était pas héroïque : limiter l’ARC et laisser de la marge pour les invités et l’hôte. Le changement important fut culturel : ils ont cessé de traiter l’ARC comme une « performance gratuite » et ont commencé à le considérer comme une ligne budgétaire avec un propriétaire.
Mini-histoire n°2 : L’optimisation qui a échoué
Une autre équipe avait une initiative « accélérer les builds ». Les runners CI étaient lents à décompresser des conteneurs et dépendances depuis un dataset ZFS. Quelqu’un a lu que « ZFS aime la RAM », ils ont donc augmenté la limite de l’ARC jusqu’au plafond et ont vu le taux de cache s’améliorer en benchmark.
En production, ce fut un désastre. Les builds se sont accélérés pendant un jour, puis sont devenus de plus en plus erratiques. Pourquoi ? Parce que les runners faisaient aussi beaucoup de travail éphémère : processus courts, caches de compilateur et fichiers temporaires. L’ARC agrandi a poussé l’hôte en pression mémoire, et le noyau a commencé à reclaimer et swapper exactement les pages dont le système de build avait besoin. Le taux de hit semblait bon, mais le temps de job de bout en bout empirait. Le hit rate est une métrique de vanité quand votre ordonnanceur pagine.
La partie vraiment douloureuse : le ralentissement ne corrélait pas proprement avec la « taille de l’ARC ». Il corrélait avec la concurrence. Avec un build, la machine allait bien. Avec dix, elle s’effondrait. C’est ce qui rend les incidents de pression mémoire si doués pour faire perdre du temps aux ingénieurs seniors : vous ne pouvez pas les reproduire sur votre laptop, et vos tableaux de bord ne crient pas « ARC a fait ça ».
Ils ont remis en arrière l’augmentation de l’ARC, puis ont pris une mesure ennuyeuse : ils ont séparé la charge CI pour que le dépaquetage et la compilation ne se battent pas sur les mêmes hôtes qui hébergent aussi des services sensibles à la latence. La leçon n’était pas « ne jamais augmenter l’ARC ». C’était : n’optimisez pas une étape tout en déstabilisant la plateforme qui l’héberge.
Mini-histoire n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Celle-ci est l’inverse du drame. Une entreprise financière (du genre qui a des fenêtres de changement et des sentiments sur le risque) utilisait ZFS sur un ensemble d’hôtes de base de données. L’équipe avait une pratique : chaque build d’hôte incluait des caps ARC explicites, une revue de la politique de swap et un « SLO de marge mémoire ». Ce n’était pas glamour. C’était documenté et appliqué via la gestion de configuration.
Un trimestre, l’équipe DB a poussé une nouvelle fonctionnalité qui augmentait la taille du working set. Sur les hôtes sans discipline, cela aurait signifié du swap surprise. Ici, l’impact fut modeste : les caches DB se sont étendus jusqu’à toucher la limite de marge, la latence a légèrement augmenté et des alertes ont déclenché pour « approche du budget mémoire ».
Parce que l’ARC était déjà plafonné, le système n’est pas entré dans une spirale de mort. L’équipe DB a vu l’alerte, a ajusté la taille de leurs caches internes et a planifié une montée en RAM lors du prochain cycle de capacité. Il n’y a pas eu de call incident, pas de panique, pas de « pourquoi la charge est à 200 ? » mystérieux.
Voilà la vérité peu sexy : la plupart des bons résultats SRE sont ennuyeux. Le meilleur tuning ARC est celui que vous avez fait il y a des mois, calmement, et que vous avez oublié jusqu’au jour où il a empêché une coupure à 3 h du matin.
Un modèle mental : quoi mesurer, pas quoi croire
Quand les gens débattent du dimensionnement de l’ARC, ils argumentent généralement par idéologie :
- Les équipes stockage : « Utilisez la RAM pour le cache ! »
- Les équipes applicatives : « Arrêtez de voler ma mémoire ! »
- Les SRE : « Je me fiche de qui gagne, je veux que la latence arrête de piquer. »
Voici un modèle qui met fin au débat : l’ARC est utile quand il réduit des E/S coûteuses sans déclencher des comportements mémoire plus coûteux. Une E/S coûteuse peut être des lectures aléatoires sur des HDD, des lectures synchrones sur le réseau, ou des recherches de métadonnées qui bloquent votre charge. Un comportement mémoire plus coûteux, c’est le swap, les blocages de reclaim et le churn de cache qui augmente la charge CPU.
Signaux que l’ARC aide
- Haut taux de hit de l’ARC et latence stable.
- Baisse des IOPS de lecture disque et latence de lecture plus faible par rapport à la baseline.
- Pas de swap, pas de pression de reclaim soutenue.
- Les applis ont assez de mémoire pour garder leurs propres caches/ensembles chauds en mémoire.
Signaux que l’ARC nuit
- Activité swap in/out pendant une charge normale.
- Augmentation des défauts majeurs de page sans amélioration de débit corrélée.
- La moyenne de charge augmente alors que le CPU reste inactif.
- L’attente I/O augmente alors que les disques ne sont pas saturés.
- Evictions fréquentes de l’ARC avec peu de bénéfice (churn de cache).
Mode opératoire de diagnostic rapide
Ceci est la séquence « vous avez 15 minutes avant que l’appel incident ne tourne au cri interprétatif ». Faites-le dans l’ordre.
1) Confirmer que c’est la pression mémoire, pas la saturation disque
Vérifiez le swap, le reclaim et les tâches en attente. Si le swap est actif et que vous voyez des indicateurs de reclaim, considérez immédiatement l’ARC comme suspect.
2) Vérifier la taille de l’ARC par rapport à la marge hôte
Regardez l’utilisation actuelle de l’ARC, les limites de l’ARC et la mémoire globale disponible. Sur les hôtes VM, vérifiez aussi l’allocation mémoire des invités et le ballooning.
3) Corréler le comportement de l’ARC avec le type de charge
Est-ce riche en métadonnées (beaucoup de fichiers, plein de stat(), décompression de conteneurs) ou riche en données (grosses lectures séquentielles) ? La stratégie de dimensionnement de l’ARC diffère.
4) Chercher le churn du cache
Les taux de hit seuls ne suffisent pas. Si l’ARC évince et recharge constamment, vous payez en CPU et en contention de verrous pour un faible gain.
5) Ne touchez aux réglages qu’après
Ne faites pas de tuning à l’aveugle. Collectez un petit paquet : stats ARC, vmstat, iostat, top et une fenêtre d’observation de 5 minutes. Ensuite ajustez zfs_arc_max de manière conservative et observez.
Tâches pratiques : commandes, sorties, interprétation (12+)
Ce sont des commandes réelles que vous pouvez exécuter sur Linux avec OpenZFS ou sur FreeBSD (avec de légères différences de chemin/sysctl). Je noterai où cela importe. Traitez les sorties comme illustratives ; vos chiffres seront différents.
Task 1: Check current ARC size and limits (Linux)
cr0x@server:~$ grep -E "c_max|c_min|size" /proc/spl/kstat/zfs/arcstats
13 c_max 4 34359738368
14 c_min 4 4294967296
7 size 4 28776239104Interprétation : Le max ARC est de 32 GiB, le min 4 GiB, la taille actuelle ~26,8 GiB. Si c’est un système avec 32 GiB de RAM exécutant des bases de données et des VMs, ce n’est pas du « cache », c’est une prise d’otage hostile.
Task 2: Check ARC efficiency quickly (arcstat)
cr0x@server:~$ arcstat 1 5
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
12:00:01 920 40 4 2 0 38 4 0 0 26.9G 32.0G
12:00:02 880 55 6 1 0 54 6 0 0 27.0G 32.0G
12:00:03 910 48 5 2 0 46 5 0 0 27.1G 32.0G
12:00:04 940 60 6 3 0 57 6 0 0 27.1G 32.0G
12:00:05 905 42 5 1 0 41 5 0 0 27.2G 32.0GInterprétation : Le taux de miss est faible. C’est bon. Mais si l’hôte swappe, « bon taux de hit » n’est pas un blanc-seing. Un cache peut être efficace et néanmoins trop grand.
Task 3: Check system memory headroom (Linux)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 64Gi 55Gi 1.2Gi 2.0Gi 7.8Gi 3.5Gi
Swap: 16Gi 2.6Gi 13GiInterprétation : « available » est de 3,5 GiB avec du swap déjà utilisé. Sur un système chargé, c’est un signal d’alerte. L’ARC peut occuper de la mémoire dont l’OS et les applis ont besoin pour la stabilité.
Task 4: Detect swap thrash and reclaim pressure (vmstat)
cr0x@server:~$ vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 1 2684352 120000 80000 900000 20 80 200 150 900 1400 12 18 58 12 0
6 2 2684800 110000 78000 880000 120 260 400 300 1100 2100 10 22 49 19 0
7 3 2686000 90000 76000 860000 300 600 800 500 1300 2600 9 25 40 26 0Interprétation : Un si/so non nul et soutenu signifie du swap actif. L’augmentation du b (proc bloqués) avec un wa plus élevé signifie souvent que le système est coincé en attente. Si cela corrèle avec l’ARC proche du max, vous avez trouvé un coupable probable.
Task 5: Confirm disk isn’t the real bottleneck (iostat)
cr0x@server:~$ iostat -x 1 3
Device r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await %util
nvme0n1 12.0 30.0 900 2200 80.0 0.20 2.10 12.5
nvme1n1 10.0 28.0 850 2100 78.5 0.18 2.00 11.0Interprétation : Faible %util et faible await suggèrent que les disques ne sont pas saturés. Si la latence est mauvaise quand même, suspectez la pression mémoire ou la contention sur des verrous, pas le débit brut du disque.
Task 6: Check ARC breakdown (data vs metadata)
cr0x@server:~$ grep -E "demand_data_bytes|demand_metadata_bytes|prefetch_data_bytes|prefetch_metadata_bytes" /proc/spl/kstat/zfs/arcstats
96 demand_data_bytes 4 12884901888
97 demand_metadata_bytes 4 13743895347
98 prefetch_data_bytes 4 1073741824
99 prefetch_metadata_bytes 4 268435456Interprétation : Les métadonnées sont énormes ici — plus grandes que les données demandées. Ce n’est pas « faux », mais cela suggère une charge comme le parcours d’arbres, de petits fichiers, ou des images de virtualisation avec beaucoup d’activité métadonnées. Si vous affamez les applis, envisagez de plafonner l’ARC et/ou réduire les sources de churn métadonnées.
Task 7: Check for ARC shrink behavior and throttling
cr0x@server:~$ grep -E "arc_shrink|arc_no_grow|memory_throttle_count" /proc/spl/kstat/zfs/arcstats
171 arc_no_grow 4 4821
198 memory_throttle_count 4 129Interprétation : memory_throttle_count indique que ZFS a dû throttler à cause de la pression mémoire. Si cela augmente pendant les incidents, l’ARC peut contribuer à la contention système globale.
Task 8: Find your current ARC tunables (Linux module parameters)
cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_arc_max
34359738368
cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_arc_min
4294967296Interprétation : Les valeurs sont en octets. Si vous ne les avez pas définies, ce sont des par défaut dérivés de la RAM totale. Les valeurs par défaut ne sont pas des écritures sacrées.
Task 9: Temporarily lower ARC max (Linux) to stop a fire
cr0x@server:~$ sudo sh -c 'echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max'
cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_arc_max
17179869184Interprétation : Cela limite la croissance future ; l’ARC ne va pas chuter instantanément au nouveau plafond, mais il va tendre à diminuer en évictions. Surveillez le swap et la latence. Si vous avez besoin d’un soulagement immédiat, vous êtes en « réponse incident » — réduisez la charge, redémarrez le pire coupable ou migrez des charges.
Task 10: Persist ARC limits (Linux, modprobe.d)
cr0x@server:~$ sudo tee /etc/modprobe.d/zfs.conf >/dev/null <<'EOF'
options zfs zfs_arc_max=17179869184
options zfs zfs_arc_min=2147483648
EOF
cr0x@server:~$ sudo update-initramfs -uInterprétation : Cela rend les limites persistantes après reboot. Les mécanismes exacts varient selon la distribution ; le point est : ne comptez pas sur « quelqu’un qui se souviendra d’un echo sysfs lors du prochain incident ».
Task 11: FreeBSD: check and set ARC limits (sysctl)
cr0x@server:~$ sysctl kstat.zfs.misc.arcstats.size
kstat.zfs.misc.arcstats.size: 28776239104
cr0x@server:~$ sysctl vfs.zfs.arc_max
vfs.zfs.arc_max: 34359738368
cr0x@server:~$ sudo sysctl vfs.zfs.arc_max=17179869184
vfs.zfs.arc_max: 34359738368 -> 17179869184Interprétation : FreeBSD utilise d’autres réglages, mais la même vérité opérationnelle s’applique : plafonner l’ARC pour protéger la santé globale du système.
Task 12: Check ZFS dataset recordsize and workload fit (because ARC isn’t magic)
cr0x@server:~$ zfs get recordsize,compression,primarycache tank/vmstore
NAME PROPERTY VALUE SOURCE
tank/vmstore recordsize 128K default
tank/vmstore compression lz4 local
tank/vmstore primarycache all defaultInterprétation : Le recordsize affecte ce qui est mis en cache et l’efficacité. Pour des images VM ou des bases de données, un mauvais recordsize peut gonfler l’empreinte du cache et augmenter l’amplification de lecture. Le dimensionnement de l’ARC ne remplace pas l’hygiène basique des datasets.
Task 13: Check primarycache/secondarycache policy (targeted relief)
cr0x@server:~$ zfs get primarycache,secondarycache tank/backup
NAME PROPERTY VALUE SOURCE
tank/backup primarycache all default
tank/backup secondarycache all default
cr0x@server:~$ sudo zfs set primarycache=metadata tank/backup
cr0x@server:~$ zfs get primarycache tank/backup
NAME PROPERTY VALUE SOURCE
tank/backup primarycache metadata localInterprétation : Si un dataset contient surtout des backups séquentiels que vous relirez rarement, mettre en cache les données est souvent une perte de RAM. Ne conserver que les métadonnées peut préserver la vitesse de parcours d’annuaire sans épingler des données en masse dans l’ARC.
Task 14: Check for ZFS prefetch effects (useful or harmful)
cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_prefetch_disable
0
cr0x@server:~$ grep -E "prefetch_data_hits|prefetch_data_misses" /proc/spl/kstat/zfs/arcstats
68 prefetch_data_hits 4 105230
69 prefetch_data_misses 4 98210Interprétation : Le prefetch peut aider les lectures séquentielles mais gaspiller le cache pour des charges aléatoires. Si les misses de prefetch sont énormes et que les prefetch data bytes sont larges, vous pourriez mettre en cache des suppositions plutôt que des faits.
Task 15: Detect “everything is slow” due to blocked tasks
cr0x@server:~$ ps -eo state,pid,comm,wchan:32 --sort=state | head
D 2314 postgres io_schedule
D 9881 java balance_pgdat
D 11202 python3 zio_wait
R 21011 top -Interprétation : Un état D avec balance_pgdat pointe vers la pression de reclaim mémoire. Si vous voyez cela pendant des incidents avec l’ARC près du max, vous regardez le motif et l’arme.
Listes de contrôle / plan étape par étape
Plan étape par étape : dimensionner l’ARC sans conjectures
- Classifiez l’hôte : appliance de stockage, hôte VM, serveur DB, usage général. Les budgets ARC diffèrent.
- Définissez un objectif de marge : décidez combien de RAM doit rester disponible pour l’OS + les applis en pic. Notez-le.
- Mesurez la baseline : collectez 30 minutes de stats ARC, activité swap, iostat et latence applicative pendant une charge typique.
- Choisissez un cap ARC initial : conservateur d’abord. Pour les hôtes VM et workloads mixtes, laisser une marge substantielle est généralement la bonne option.
- Appliquez le cap temporairement : changez
zfs_arc_maxen live, observez les améliorations du swap/reclaim et toute baisse du hit rate. - Validez l’impact sur la charge : surveillez p95/p99 de latence, pas seulement le débit. Le tuning ARC concerne la latence tail.
- Rendez-le persistant : gestion de configuration, réglages au démarrage et plan de rollback.
- Réévaluez après les changements : nouvelles versions d’applis, nouveaux datasets, nouvelle densité VM — le dimensionnement ARC n’est pas « régler et oublier ».
Checklist opérationnelle : avant de changer l’ARC en production
- Le swap est-il actuellement actif ? Si oui, réduisez d’abord le risque : allégez la charge ou scale out.
- Avez-vous un accès distant hors-bande ? Les incidents mémoire peuvent rendre SSH « art interactif ».
- Savez-vous revenir en arrière rapidement ?
- Avez-vous une fenêtre d’observation de 10 minutes sous charge stable ?
- Avez-vous capturé les métriques « avant » (taille ARC, vmstat, iostat, latence) ?
Erreurs fréquentes : symptômes et corrections
Mistake 1: “ARC should be as big as possible.”
Symptômes : L’usage du swap augmente sur plusieurs jours ; la p99 spike pendant les jobs cron ; la moyenne de charge grimpe alors que le CPU n’est pas occupé ; des OOM aléatoires.
Correction : Plafonnez zfs_arc_max pour laisser une vraie marge. Sur les hôtes VM, soyez plus strict que sur des boîtes de stockage dédiées. Validez avec vmstat et la latence applicative.
Mistake 2: Tuning based on hit rate alone
Symptômes : Le hit rate s’améliore mais la performance globale se dégrade ; plus de changements de contexte ; plus de temps noyau ; blocages visibles par les utilisateurs.
Correction : Traitez le hit rate comme métrique de support. Priorisez l’activité swap, la pression de reclaim, les tâches bloquées et la latence tail.
Mistake 3: Ignoring metadata-heavy workloads
Symptômes : L’ARC se remplit rapidement pendant des scans de backup, l’extraction de couches de conteneurs ou l’indexation de fichiers ; la pression mémoire corrèle avec « beaucoup d’opérations fichier », pas avec le débit.
Correction : Envisagez des contrôles au niveau dataset comme primarycache=metadata pour les datasets volumineux, et plafonnez l’ARC. Examinez aussi les patterns de charge : peut-on planifier les parcours d’arbre hors-pointe ?
Mistake 4: Overcommitting VM hosts without budgeting ARC
Symptômes : L’hôte swappe tandis que les invités balloon ; incidents de noisy-neighbor ; pauses imprévisibles.
Correction : Traitez l’ARC comme une réservation fixe. Mettez un cap et gardez-le stable. Surveillez la mémoire « available » de l’hôte, pas seulement le « used ».
Mistake 5: Making changes that don’t persist
Symptômes : Le système est correct après tuning, puis après reboot l’incident revient ; personne ne se souvient pourquoi.
Correction : Persistez via options de module (Linux) ou loader/sysctl (FreeBSD), sous gestion de configuration avec historique de changements.
Mistake 6: Blaming disks when the real issue is reclaim
Symptômes : Rapports « le stockage est lent », mais iostat montre une faible utilisation et une latence correcte. La charge est élevée. Beaucoup de tâches sont bloquées.
Correction : Regardez vmstat, le swap et les tâches en état D. Si le reclaim est en cause, le dimensionnement de l’ARC fait partie de la solution.
Mistake 7: Setting ARC min too high
Symptômes : Même sous pression, l’ARC refuse de se réduire suffisamment ; risque d’OOM augmenté ; swap persiste.
Correction : Gardez zfs_arc_min modeste sauf si vous avez une appliance de stockage dédiée avec des besoins prévisibles.
Blague en une phrase #2 : Mettre ARC min à « ne jamais réduire » c’est comme boulonner votre chaise de bureau au sol — stable, certes, mais maintenant vous faites vos réunions depuis le couloir.
FAQ
1) How much RAM should I give to ARC?
Il n’y a pas de chiffre universel. Commencez par réserver assez pour l’OS et vos charges principales en pic (VMs, bases de données, JVM). Allouez ensuite le reste à l’ARC avec un cap conservateur. Les boîtes de stockage dédiées peuvent se permettre un ARC plus grand ; les hôtes à usage mixte en général non.
2) Why does my server show almost no free memory? Is that bad?
Pas forcément. Linux utilise agressivement la RAM pour les caches. Le signe dangereux n’est pas « peu de mémoire libre », mais « available est faible » plus activité swap, blocages de reclaim ou pics de latence.
3) Should I disable swap on ZFS systems?
Généralement non. Un petit swap contrôlé peut prévenir des OOM abrutis. L’objectif est d’éviter le thrashing actif. Si le swap est fortement utilisé en charge normale, corrigez le budget mémoire (y compris les caps ARC) plutôt que de jouer au whack-a-mole avec le swap.
4) Does adding L2ARC let me shrink ARC safely?
L2ARC peut aider les charges en lecture où le working set dépasse la RAM, mais ce n’est pas un remplacement gratuit pour l’ARC. L2ARC consomme toujours de la mémoire pour les métadonnées et peut ajouter du trafic d’écriture aux SSD. Réduisez l’ARC pour protéger la stabilité ; ajoutez L2ARC seulement après avoir prouvé que les misses de lecture sont votre goulet d’étranglement.
5) Why does ARC not shrink immediately after lowering zfs_arc_max?
L’éviction de l’ARC est pilotée par l’activité et la pression. Abaisser le cap change l’objectif, mais l’ARC doit encore évincer des buffers au fil du temps. Si vous avez besoin d’un soulagement immédiat, réduisez la charge, arrêtez la charge qui gonfle le cache ou planifiez un redémarrage contrôlé du consommateur mémoire lourd — parce que vous êtes déjà en mode incident.
6) Is ARC sizing different for HDD pools vs NVMe pools?
Oui, parce que la valeur d’un miss dépend du coût du miss. Les lectures aléatoires sur HDD sont coûteuses ; l’ARC aide beaucoup. Les misses NVMe sont moins chers ; l’ARC aide encore (surtout pour les métadonnées), mais vous pouvez atteindre la contention CPU ou mémoire avant que le stockage ne devienne le facteur limitant. Ne dépeuplez pas le système juste pour éviter une lecture NVMe de 200 microsecondes.
7) How do I know if my workload is metadata-heavy?
Regardez la répartition de l’ARC (demand metadata bytes vs demand data bytes), et observez les patterns : beaucoup de stat(), parcours d’arborescence, petits opens de fichiers, couches de conteneurs, installations de paquets. Les charges riches en métadonnées bénéficient du cache de métadonnées, mais elles peuvent aussi gonfler rapidement l’ARC.
8) Should I set primarycache=metadata for VM datasets?
Pas par défaut. Les images VM bénéficient souvent du cache de données parce qu’elles relisent des blocs. Cependant, pour des datasets de backup, d’archive ou écrits-une-fois/lus-rarement, primarycache=metadata peut récupérer de la RAM sans perte de performance significative.
9) What’s the safest way to change ARC limits in production?
Changez zfs_arc_max progressivement, pendant une charge stable, avec rollback clair. Surveillez swap, vmstat et latence pendant au moins plusieurs minutes. Puis persistez le réglage via gestion de configuration et planifiez une revue post-changement.
10) I capped ARC and performance got worse. Did I do something wrong?
Peut-être, ou peut-être avez-vous simplement exposé le vrai goulet d’étranglement (disque, réseau, CPU). Si la latence de lecture a augmenté et que les disques sont maintenant plus occupés, l’ARC masquait un stockage lent. Si la performance a empiré mais que le swap a cessé, vous avez troqué vitesse contre stabilité — ce qui peut être la bonne décision. L’étape suivante correcte est d’adresser la contrainte nouvellement visible plutôt que de regonfler l’ARC aveuglément.
Conclusion
L’ARC est un outil de performance, pas un droit acquis. Il doit concourir pour la mémoire, mais il ne doit pas gagner en mettant le reste du système K.O. Un ARC surdimensionné ne crie pas sa défaillance ; il échoue latéralement — via le swap, les blocages de reclaim, les tâches bloquées et la latence tail qui font paraître des disques parfaitement sains coupables.
Dimensionnez l’ARC comme vous dimensionneriez n’importe quoi d’autre en production : définissez une marge, mesurez les vrais goulets d’étranglement, faites de petits changements et persistez les réglages ennuyeux qui vous évitent les appels incident. Le meilleur cache est celui qui accélère votre charge sans transformer votre système d’exploitation en tribunal d’arbitrage mémoire.