Si vous utilisez ZFS assez longtemps, quelqu’un finira par paniquer à propos de la « disparition » de la RAM.
On vous montrera un tableau de bord où la « mémoire libre » est presque nulle, et on prononcera la phrase que tout SRE entend en rêve :
« ZFS bouffe toute notre RAM. »
Voici la chute : ZFS est censé utiliser votre RAM. ZFS traite la mémoire comme une pédale d’accélérateur, pas comme une vitrine de musée.
L’astuce n’est pas de garder de la RAM « libre ». L’astuce est de la garder utile — sans affamer vos applications, sans déclencher des tempêtes de swap,
et sans confondre un cache sain avec une fuite.
ARC en une phrase
ARC (Adaptive Replacement Cache) est le cache en mémoire de ZFS pour les blocs récemment et fréquemment utilisés — données et métadonnées —
conçu pour transformer des lectures disque coûteuses en lectures RAM bon marché, en s’adaptant dynamiquement à votre charge de travail.
Blague n°1 : « La RAM libre » est comme un siège vide dans un avion — rassurant à regarder, mais vous le payez de toute façon.
Pourquoi la « RAM libre » est un mythe (en production)
Sur un OS moderne, la RAM inutilisée est une opportunité gâchée. Le noyau utilise agressivement la mémoire pour des caches : cache système de fichiers,
cache inode/dentry, allocations slab, et l’ARC de ZFS. Ce n’est pas une bizarrerie de ZFS ; c’est de l’économie basique.
La RAM est le niveau de stockage le plus rapide dont vous disposez.
La confusion vient des tableaux de bord et des métriques simplistes. Beaucoup de graphiques considèrent encore « mémoire utilisée » comme suspecte et
« mémoire libre » comme sûre. C’est l’inverse. Ce que vous voulez, c’est :
- Peu d’activité de swap (surtout pas d’échanges soutenus).
- Un comportement de reclaim des pages sain (pas de thrashing, pas de kills OOM).
- Des latences applicatives stables sous charge.
- Un comportement ARC prévisible par rapport à votre charge de travail.
L’ARC peut être volumineuse et néanmoins inoffensive — si elle peut se réduire quand la pression mémoire arrive, et si elle n’envoie pas vos charges en swap.
Inversement, vous pouvez avoir de la « RAM libre » et être lent, si votre working set ne tient pas en cache et que vos disques effectuent des E/S aléatoires.
Une manière pratique d’y penser : la RAM libre n’est pas un objectif ; la RAM reclaimable l’est. L’ARC doit pouvoir être récupérée sous pression,
et le système doit rester stable lorsqu’elle l’est.
Ce qu’est réellement l’ARC (et ce que ce n’est pas)
ARC n’est pas le page cache Linux (mais il lui fait concurrence)
Si vous êtes sur Linux avec OpenZFS, vous avez effectivement deux systèmes de cache en jeu :
le page cache Linux et l’ARC de ZFS. ZFS utilise l’ARC pour le stockage géré par ZFS. Linux utilise le page cache pour les E/S de fichiers
et tout le reste lié aux mécanismes de cache du noyau.
Selon votre charge et le chemin d’E/S, vous pouvez vous retrouver à double-cacher ou à vous battre pour la mémoire.
Par exemple, des charges de bases de données qui implémentent déjà leur propre cache peuvent finir par payer le cache trois fois :
cache applicatif, ARC, et (parfois) des effets du page cache selon I/O direct vs buffered.
ARC est adaptatif (et sélectif sur ce qu’il garde)
L’ARC n’est pas un cache bête du type « garder les N derniers blocs ». Il utilise un algorithme de remplacement adaptatif conçu pour équilibrer :
- La récence : « J’ai utilisé ceci récemment, je pourrais l’utiliser à nouveau bientôt. »
- La fréquence : « J’utilise ceci de façon répétée dans le temps. »
Cela compte dans des systèmes réels. Considérez :
un job nocturne qui scanne des téraoctets séquentiellement (forte récence, faible réutilisation) versus un datastore VM avec des blocs « chauds »
lus répétitivement (forte fréquence). L’objectif de l’ARC est d’éviter d’être « pollué » par des scans uniques tout en capturant les données véritablement chaudes.
ARC met en cache les métadonnées, ce qui peut être plus important que les données
Dans de nombreux déploiements ZFS en production, le cache des métadonnées fait la différence entre « réactif » et « pourquoi mon ls bloque ? ».
Les métadonnées incluent dnodes, blocs indirects, structures de répertoires et diverses structures de recherche.
Si vous avez déjà vu un système de stockage tomber sous des charges de « petits fichiers », vous avez rencontré les métadonnées de la pire des façons.
Vous pouvez disposer d’un bon débit disque et pourtant être bloqué parce que le système fait du pointer-chasing sur disque
pour des métadonnées qui auraient dû être en RAM.
Ce qui vit dans l’ARC : données, métadonnées et les surprises
Blocs de données vs blocs de métadonnées
L’ARC contient des blocs mis en cache depuis votre pool. Certains sont des données de fichiers. D’autres sont des métadonnées.
Le mélange évolue selon la charge. Une ferme de VM a tendance à avoir beaucoup de lectures répétées et un turnover de métadonnées ; une archive média
peut essentiellement streamer de grands blocs une fois ; un serveur Git peut être metadata-heavy avec des rafales.
La prélecture peut aider, et elle peut aussi mettre le feu à votre RAM
ZFS effectue de la lecture anticipée (prefetch) dans divers scénarios. Quand cela fonctionne, cela transforme des lectures séquentielles en débit fluide.
Quand cela rate — comme lorsque votre charge « séquentielle » est en réalité de nombreux flux entrelacés — cela peut inonder l’ARC de
données qui ne seront pas réutilisées.
Conséquence réelle : vous pouvez évincer des métadonnées utiles pour faire de la place à des données préchargées inutiles.
Ensuite tout devient plus lent, et les gens blâment la « surcharge ZFS » alors que c’est en fait de la pollution de cache.
Blocs compressés et le calcul de RAM que l’on se trompe
ZFS stocke des blocs compressés sur disque. L’ARC stocke typiquement les données selon des détails d’implémentation et la charge,
mais la vérité opérationnelle est : la compression change votre modèle mental. Si vous compressez bien, la capacité effective du cache
peut augmenter parce que plus de données logiques tiennent par unité physique. Mais le coût CPU et l’overhead mémoire pour la tenue
des métadonnées sont réels, et ils se voient à grande échelle.
Dedup : le « tiens ma bière » de la consommation de RAM
La déduplication dans ZFS est célèbre pour être à la fois puissante et dangereuse. La table de dédup (DDT) a besoin d’un accès rapide, et
accès rapide signifie mémoire. Si vous activez la dédup sans assez de RAM pour le working set du DDT, vous pouvez transformer un système de stockage
en générateur d’E/S aléatoires avec une activité secondaire de misère.
Blague n°2 : Activer la dédup sur une machine en manque de RAM, c’est comme adopter un tigre parce que la nourriture pour chats était en promo.
Comment l’ARC croît, décroît et refuse parfois de « lâcher »
La taille de l’ARC est une négociation avec l’OS
L’ARC a une plage de taille cible, gouvernée par des réglages comme zfs_arc_min et zfs_arc_max.
Le noyau appliquera une pression quand d’autres sous-systèmes auront besoin de mémoire.
Dans un système bien comporté, l’ARC grandit quand la RAM est disponible et se réduit quand elle est nécessaire ailleurs.
Dans un système mal compris, on voit l’ARC à « son maximum » et on suppose que c’est une fuite. Généralement ce n’est pas le cas.
L’ARC se comporte comme prévu : elle a trouvé de la mémoire libre et l’a utilisée pour accélérer les lectures.
Pourquoi l’ARC ne se réduit parfois pas « assez vite »
Il existe des cas où la réduction de l’ARC peut être en retard face à une demande mémoire soudaine :
pics de conteneurs, expansions de heap JVM, ou une expansion d’urgence du page cache pour une charge non-ZFS.
L’ARC est reclaimable, mais pas nécessairement immédiatement reclaimable, et le chemin de « pression » à « octets libérés »
peut avoir une latence.
Lorsque cette latence rencontre des charges agressives, vous voyez du swapping, du burn CPU de kswapd, et des pics de latence en queue.
C’est là que l’ARC devient impopulaire politiquement.
La douleur particulière de la virtualisation et des « voisins bruyants »
Dans les environnements d’hyperviseur (ou grands hôtes de conteneurs), le comptage mémoire devient confus. Les invités ont leurs propres caches.
L’hôte a l’ARC. L’hôte peut aussi avoir du page cache pour d’autres fichiers. Si vous surabonnez la mémoire ou autorisez
le ballooning/overcommit sans garde-fous, l’ARC devient le bouc émissaire d’une planification capacitaire fondamentalement mauvaise.
Faits & histoire : comment on en est arrivé là
- ZFS est né chez Sun Microsystems comme un design « pool de stockage + système de fichiers », pas comme un gestionnaire de volumes ajouté par-dessus.
- L’ARC est basé sur l’algorithme Adaptive Replacement Cache, qui améliore le simple LRU en équilibrant récence et fréquence.
- ZFS a popularisé le checksum bout-en-bout pour l’intégrité des données, ce qui augmente le travail des métadonnées — et rend le cache des métadonnées plus précieux.
- La philosophie « utiliser la RAM comme cache » préexistait à ZFS ; les noyaux Unix ont longtemps utilisé la mémoire libre pour du caching, mais ZFS l’a rendue impossible à ignorer.
- Les premières recommandations ZFS étaient « la RAM est reine » en partie parce que les disques étaient plus lents et l’I/O aléatoire était brutalement coûteux comparé à la RAM.
- L2ARC (cache secondaire) est arrivé pour étendre le cache sur des dispositifs rapides, mais ce n’est pas gratuit : il a besoin de métadonnées dans l’ARC pour être utile.
- La déduplication est devenue notoire parce qu’elle a déplacé une optimisation traditionnellement hors-ligne vers un chemin temps réel, avide de RAM.
- OpenZFS a porté ZFS sur Linux et d’autres plateformes, où il a dû coexister avec différents sous-systèmes VM et de cache, changeant les réalités de tuning.
- NVMe a changé la donne : les disques sont devenus si rapides que les mauvaises décisions de cache sont parfois moins visibles — jusqu’à ce que la latence de queue arrive.
Trois mini-histoires du monde de l’entreprise
Mini-histoire n°1 : L’incident causé par une mauvaise hypothèse (« La RAM libre est saine »)
Une entreprise de taille moyenne exploitait un cluster NFS sur ZFS servant des répertoires personnels et des artefacts de build.
Un nouveau manager — intelligent, rapide et fraîchement formé sur une autre pile — a déployé un changement de « durcissement » mémoire :
limiter agressivement l’ARC pour que « au moins 40% de la RAM reste libre ». Ça paraissait raisonnable sur une feuille de calcul.
La première semaine s’est bien passée. Les tableaux de bord étaient rassurants : beaucoup de vert, beaucoup de « mémoire libre ».
Puis le cycle de release trimestriel est arrivé. Les jobs de build se sont multipliés, les petits fichiers ont explosé, et les serveurs NFS ont commencé
à cafouiller. Pas en panne, juste assez lents pour que tout le reste semble cassé.
Le symptôme qui a fait monter l’incident n’était pas « forte utilisation disque ». C’était le genre moche :
iowait en hausse, latence des opérations métadonnées en pic, et files d’attente des threads NFS.
Le pool n’était pas saturé en débit. Il se noyait dans des lectures aléatoires de métadonnées qui tenaient autrefois dans l’ARC.
Le postmortem n’était pas une affaire de blâme. C’était une mauvaise hypothèse : « la mémoire libre est un indicateur de stabilité ».
La correction fut aussi peu glamour : autoriser l’ARC à croître, mais fixer un plafond sain basé sur l’espace réel pour les applications,
et ajouter des alertes sur l’activité de swap et les taux d’éviction de l’ARC — pas sur la « RAM libre ».
La leçon : si vous traitez la RAM comme un trophée, ZFS traitera vos disques comme un bloc-notes.
Mini-histoire n°2 : L’optimisation qui s’est retournée contre eux (L2ARC partout)
Un autre atelier avait un pool ZFS supportant un cluster de virtualisation. Les lectures étaient le point douloureux, donc quelqu’un a proposé
d’ajouter des dispositifs L2ARC. Ils avaient des SSD de rechange, et le plan était simple : « Ajouter L2ARC et le hit ratio va exploser. »
C’est facile à vendre car c’est du matériel tangible.
Ils ont ajouté un gros L2ARC, surveillé les graphiques, et… rien de magique ne s’est produit. En fait, sous certaines charges,
la latence s’est même détériorée. Ce n’était pas catastrophique ; c’était insidieux. Les VMs semblaient « collantes » lors des pics de boot matinaux,
et les charges aléatoires devenaient plus piquantes.
Le coupable n’était pas les SSD. C’était la mémoire. L2ARC a besoin de métadonnées dans l’ARC pour être efficace. Plus le L2ARC est grand,
plus vous dépensez d’overhead ARC pour l’indexer. Sur un hôte déjà serré en RAM, la pression supplémentaire a poussé l’ARC
à évincer plus souvent les métadonnées dont le système avait le plus besoin.
Le rollback n’a pas été dramatique. Ils ont réduit la taille du L2ARC, ajouté de la RAM au prochain renouvellement, et ajusté les attentes :
L2ARC aide surtout quand le working set est plus grand que la RAM mais reste « cacheable », et quand vous pouvez payer l’overhead mémoire.
Sinon, vous avez construit une façon très coûteuse de rendre votre cache moins stable.
La leçon : le caching n’est pas additif ; c’est un budget. Si vous le dépensez deux fois, vous faites faillite en latence.
Mini-histoire n°3 : La pratique ennuyeuse qui a sauvé la mise (mesurer avant de tuner)
Une équipe de services financiers utilisait ZFS pour une pipeline d’ingestion de fichiers. Ils n’étaient pas les plus bruyants, mais ils étaient disciplinés.
Leur pratique était douloureusement ennuyeuse : avant tout « tuning », ils capturaient un bundle de métriques de référence — stats ARC, latence I/O,
activité swap, et paramètres par dataset recordsize/compression. Chaque changement venait avec une comparaison avant/après.
Un après-midi, la latence d’ingestion a doublé. Le bouc émissaire facile était l’ARC : « Peut-être que le cache thrash. »
Mais leur baseline disait autre chose. Le hit ratio ARC était stable. Les évictions n’étaient pas inhabituelles. Ce qui avait changé, c’était
la pression mémoire : un nouveau sidecar avait été déployé avec un heap non borné.
Le système ne tombait pas parce que l’ARC était gourmande ; il tombait parce que l’hôte était sur-engagé.
L’ARC faisait ce qu’elle pouvait — se réduire sous pression — mais l’autre processus continuait d’exploser, poussant la machine en swap.
Leurs graphiques l’ont montré clairement : le swap-in/out a augmenté en premier, puis la latence, puis le temps CPU passé en reclaim.
La correction n’était pas un réglage ZFS ésotérique. C’était une limite de ressource et un rollback d’un mauvais déploiement.
La pratique ennuyeuse — capturer des baselines et surveiller les bons indicateurs — les a empêchés d’aggraver la situation en étranglant aveuglément l’ARC.
La leçon : la plupart des « problèmes mémoire ZFS » sont en réalité des problèmes mémoire système qui portent un chapeau ZFS.
Tâches pratiques : commandes, sorties et ce qu’elles signifient
L’objectif ici n’est pas de mémoriser des commandes. C’est de se forger une mémoire musculaire :
vérifier la charge, confirmer la pression mémoire, puis décider si l’ARC aide ou nuit.
Les commandes ci-dessous supposent un système Linux avec OpenZFS installé ; adaptez les chemins pour d’autres plateformes.
Task 1: See overall memory reality (not “free RAM” panic)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 251Gi 41Gi 2.1Gi 1.2Gi 208Gi 198Gi
Swap: 16Gi 0B 16Gi
Interprétation : « Free » est bas, mais « available » est énorme. Cela signifie généralement que le système met beaucoup en cache et peut récupérer la mémoire.
Si le swap est calme et que « available » est sain, c’est probablement OK.
Task 2: Check if swapping is actually happening
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 2212140 10240 189512000 0 0 12 44 520 880 6 2 91 1 0
1 0 0 2198840 10240 189625000 0 0 0 0 500 860 5 2 92 1 0
4 1 0 2101020 10240 189540000 0 0 220 180 1100 1600 10 4 74 12 0
3 0 0 2099920 10240 189520000 0 0 140 120 920 1300 8 3 81 8 0
2 0 0 2103200 10240 189610000 0 0 30 60 600 900 5 2 91 2 0
Interprétation : Surveillez si/so (swap in/out). Des valeurs soutenues non nulles signifient que la machine est sous pression mémoire.
Un peu d’I/O wait (wa) n’est pas automatiquement la faute de l’ARC ; corrélez avec les misses ARC et la latence disque.
Task 3: Read ARC size and limits directly
cr0x@server:~$ grep -E '^(c|size|c_min|c_max|memory_throttle_count)' /proc/spl/kstat/zfs/arcstats
c 4 214748364800
c_min 4 10737418240
c_max 4 214748364800
size 4 198742182912
memory_throttle_count 4 0
Interprétation : size est la taille actuelle de l’ARC. c est la cible. c_max est le plafond.
Si memory_throttle_count augmente, l’ARC a rencontré des événements de pression mémoire à investiguer.
Task 4: Check ARC hit/miss behavior (is ARC helping?)
cr0x@server:~$ grep -E '^(hits|misses|demand_data_hits|demand_data_misses|demand_metadata_hits|demand_metadata_misses)' /proc/spl/kstat/zfs/arcstats
hits 4 18230933444
misses 4 1209933221
demand_data_hits 4 12055411222
demand_data_misses 4 902331122
demand_metadata_hits 4 5800122201
demand_metadata_misses 4 307602099
Interprétation : Un grand nombre de hits par rapport aux misses est bon, mais ne vénérez pas le hit ratio.
Ce qui compte, c’est la latence et la charge disque. Un « bon » ratio peut quand même être trop lent si vos misses sont coûteux (lectures aléatoires sur HDD),
et un « mauvais » ratio peut être acceptable si votre pool est NVMe et que votre charge est en streaming.
Task 5: Watch ARC live with arcstat (when installed)
cr0x@server:~$ arcstat 1 5
time read miss miss% dmis dm% pmis pm% mmis mm% arcsz c
12:01:01 812 42 5 30 4 8 1 4 0 185G 200G
12:01:02 900 55 6 40 4 10 1 5 1 185G 200G
12:01:03 1100 220 20 190 17 18 2 12 1 184G 200G
12:01:04 980 180 18 150 15 20 2 10 1 184G 200G
12:01:05 860 60 7 45 5 10 1 5 1 184G 200G
Interprétation : Un pic de misses pendant un scan batch est normal. Une tempête de misses persistante en « steady state »
signifie souvent que votre working set ne tient pas, qu’il y a pollution de prélecture, ou un changement de charge (nouveau dataset, nouveau pattern).
Task 6: Check for memory reclaim stress (Linux)
cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.00 avg60=0.05 avg300=0.12 total=1843812
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
Interprétation : PSI memory « some » indique du temps passé bloqué par la pression mémoire ; « full » est pire (tâches complètement bloquées).
Une hausse de PSI accompagnée d’activité swap et d’ARC au cap est un signal pour revisiter les budgets mémoire.
Task 7: Confirm pool health and obvious bottlenecks
cr0x@server:~$ zpool status -xv
all pools are healthy
Interprétation : Ne pas tuner les caches sur un pool malade. Si vous avez des erreurs, un resilvering, ou des vdevs dégradés, votre « problème ARC »
peut être un « problème matériel ».
Task 8: Observe I/O latency, not just throughput
cr0x@server:~$ zpool iostat -v 1 3
capacity operations bandwidth
pool alloc free read write read write
tank 48.2T 21.6T 8200 1100 690M 120M
raidz2-0 48.2T 21.6T 8200 1100 690M 120M
sda - - 1020 130 85M 10M
sdb - - 1015 135 86M 11M
sdc - - 1040 140 86M 10M
sdd - - 1030 135 85M 10M
Interprétation : Ceci montre opérations et bande passante, mais pas la latence. Si les choses « semblent lentes », couplez avec des outils comme
iostat -x pour voir await/util, et corrélez avec les misses ARC.
Task 9: Check device latency with iostat
cr0x@server:~$ iostat -x 1 3
Device r/s w/s rMB/s wMB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
sda 1020.0 130.0 85.0 10.0 0.0 8.0 0.00 5.80 9.10 6.20 9.50 85.3 79.1 0.40 46.0
sdb 1015.0 135.0 86.0 11.0 0.0 9.0 0.00 6.20 9.40 6.10 9.60 86.7 83.1 0.41 46.5
Interprétation : Une hausse de r_await et un %util élevé pendant des pics de misses ARC signifient que vos disques paient les misses de cache.
Si la latence est déjà faible (par ex. NVMe), les misses ARC peuvent ne pas être le coupable.
Task 10: Identify which datasets are configured to behave expensively
cr0x@server:~$ zfs get -o name,property,value -s local,received recordsize,primarycache,secondarycache,compression tank
NAME PROPERTY VALUE
tank compression lz4
tank primarycache all
tank recordsize 128K
Interprétation : primarycache=all signifie que les données et métadonnées sont mises en cache dans l’ARC.
Pour certaines charges (bases de données, streaming volumineux), vous pouvez choisir metadata pour réduire la pression ARC.
Ne le faites pas par superstition — mesurez.
Task 11: Check whether a workload is bypassing cache expectations
cr0x@server:~$ zfs get -o name,property,value atime,sync,logbias,primarycache tank/vmstore
NAME PROPERTY VALUE
tank/vmstore atime off
tank/vmstore sync standard
tank/vmstore logbias latency
tank/vmstore primarycache all
Interprétation : Des réglages comme sync et logbias ne changent pas directement l’ARC, mais ils modifient le comportement I/O.
Si les écritures sont lentes et causent du backpressure, les lectures peuvent en souffrir et le « débat ARC » devient une distraction.
Task 12: Set a temporary ARC cap (carefully) for experiments
cr0x@server:~$ sudo sh -c 'echo $((64*1024*1024*1024)) > /sys/module/zfs/parameters/zfs_arc_max'
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_max
68719476736
Interprétation : Cela fixe le max de l’ARC à 64 GiB (la valeur est en octets). Utilisez cela pour tester des hypothèses d’espace libre, pas comme correctif permanent.
Le tuning permanent doit être fait via la configuration du paramètre du module de votre distro pour persister au reboot.
Task 13: Force the question—does performance track ARC size or disk latency?
cr0x@server:~$ sudo sh -c 'echo $((128*1024*1024*1024)) > /sys/module/zfs/parameters/zfs_arc_max'
cr0x@server:~$ sleep 10
cr0x@server:~$ grep -E '^(size|c|c_max)' /proc/spl/kstat/zfs/arcstats
c 4 137438953472
c_max 4 137438953472
size 4 132001234944
Interprétation : Augmenter temporairement le cap ARC et observer si la latence s’améliore et si les misses baissent.
Si rien ne change, votre goulot d’étranglement peut être le chemin d’écriture, le CPU, le réseau ou le pattern applicatif.
Task 14: Spot ARC-related kernel messages
cr0x@server:~$ dmesg -T | grep -i -E 'arc|spl|zfs' | tail -n 10
[Thu Dec 25 09:44:10 2025] ZFS: Loaded module v2.2.4-1
[Thu Dec 25 10:02:31 2025] ZFS: ARC size 197G, target 200G, min 10G, max 200G
Interprétation : Cherchez des avertissements sur la limitation mémoire, des échecs d’allocation, ou des événements répétitifs de reclaim.
Si les logs sont bruyants, vous êtes au-delà de « l’ARC est grande » et dans « l’ARC se bat avec le noyau ».
Task 15: Determine if your workload is dominated by metadata
cr0x@server:~$ grep -E '^(demand_metadata_hits|demand_metadata_misses|demand_data_hits|demand_data_misses)' /proc/spl/kstat/zfs/arcstats
demand_data_hits 4 12055411222
demand_data_misses 4 902331122
demand_metadata_hits 4 5800122201
demand_metadata_misses 4 307602099
Interprétation : Si les misses de métadonnées sont significatives et corrélées avec des opérations de répertoire lentes, des ouvertures de fichiers lentes ou de fortes IOPS disque,
priorisez le maintien des métadonnées chaudes : évitez la pollution du cache, évitez des caps ARC trop petits, et considérez des réglages de dataset adaptés.
Feuille de route pour un diagnostic rapide
Quand quelqu’un vous ping « ZFS utilise toute la RAM » ou « ZFS est lent », vous n’avez pas le temps pour un séminaire de philosophie.
Vous avez besoin d’une séquence courte et fiable qui trouve rapidement le goulot.
Step 1: Is the host under memory pressure or just caching?
- Vérifiez
free -het concentrez-vous sur available, pas sur free. - Vérifiez
vmstat 1pour dessi/sosoutenus > 0. - Vérifiez PSI mémoire (
/proc/pressure/memory) pour une augmentation de « some/full ».
Si le swap est actif et PSI augmente, vous avez un problème de pression mémoire. L’ARC peut être impliquée, mais rarement le seul acteur.
Step 2: Are reads slow because ARC is missing, or because disks are slow anyway?
- Vérifiez hits/misses ARC (
/proc/spl/kstat/zfs/arcstatsouarcstat). - Vérifiez la latence disque (
iostat -x 1) et le comportement du pool (zpool iostat 1).
Si les misses ARC augmentent et que la latence disque augmente, votre cache ne couvre pas votre working set — ou il est pollué.
Si les misses augmentent mais que les disques restent basse-latence, votre plainte de performance peut venir d’ailleurs (CPU, réseau, appli).
Step 3: Is the workload changing the cache economics?
- Cherchez des scans massifs, backups, jobs de reindex, pics de boot VM, ou réplications.
- Identifiez si les misses de métadonnées ont augmenté (petits fichiers, millions d’inodes).
- Revue des propriétés de dataset :
primarycache,recordsize, compression, sync/logbias.
Beaucoup d’« incidents ARC » sont en réalité des incidents « un job batch est passé ». Votre réponse devrait être d’isoler ou planifier le job,
pas de saboter définitivement le caching.
Step 4: Decide: tune ARC limits, tune workload, or add RAM
- Si l’hôte swappe : réservez de la marge (cap ARC) et corrigez le hog mémoire.
- Si les disques sont saturés par des misses : augmentez le cache effectif (plus de RAM, meilleure politique de cache, réduire la pollution).
- Si la latence est correcte : cessez d’y toucher et attaquez le vrai goulot.
Listes de contrôle / plan étape par étape
Checklist A: « L’ARC nuit-elle à mes applications ? »
- Confirmer l’activité de swap :
cr0x@server:~$ vmstat 1 10Recherchez des
si/sosoutenus et unewaen hausse. - Confirmer la disponibilité mémoire :
cr0x@server:~$ free -hSi
availableest bas et diminue, vous manquez réellement de mémoire. - Vérifier le cap et la taille de l’ARC :
cr0x@server:~$ grep -E '^(size|c_max|c_min|memory_throttle_count)' /proc/spl/kstat/zfs/arcstatsSi l’ARC est au cap et que memory_throttle_count augmente, envisagez de libérer de la marge.
- Corréler avec la latence applicative et les logs OOM :
cr0x@server:~$ dmesg -T | tail -n 50Si vous voyez des OOM kills, le dimensionnement ARC n’est pas la cause racine ; c’est l’overcommit.
Checklist B: « L’ARC est-elle trop petite pour cette charge ? »
- Mesurer les misses ARC pendant la fenêtre de plainte :
cr0x@server:~$ arcstat 1 30Des misses persistantes pendant une charge stable sont un signal d’alerte.
- Vérifier la latence disque en même temps :
cr0x@server:~$ iostat -x 1 30Si les awaits augmentent pendant les tempêtes de misses, le pool en paie le prix.
- Tester une augmentation contrôlée du max ARC (si vous avez de la marge) :
cr0x@server:~$ sudo sh -c 'echo $((192*1024*1024*1024)) > /sys/module/zfs/parameters/zfs_arc_max'Observez si la latence s’améliore et si les misses diminuent. Si oui, la solution est généralement « plus de RAM ou meilleure isolation ».
Checklist C: « Garder les métadonnées chaudes, arrêter la pollution du cache »
- Identifier les jobs de type scan (backup, scrub, rsync, reindex) et les planifier hors-peak.
- Envisager
primarycache=metadatapour les datasets en streaming qui ne bénéficient pas du caching des données :cr0x@server:~$ sudo zfs set primarycache=metadata tank/archiveCela peut réduire le churn ARC tout en gardant la traversée des répertoires rapide.
- Valider avec les stats ARC : les misses metadata doivent baisser ; les IOPS disque doivent se stabiliser.
Erreurs courantes (symptômes et corrections)
Mistake 1: Alerting on “free RAM”
Symptômes : Pages d’astreinte constantes, pas de problème de performance réel, pression pour « corriger la mémoire ZFS ».
Correction : Alertez sur l’activité de swap (vmstat si/so), PSI mémoire « full », événements OOM, et latence applicative.
Utilisez la mémoire « available », pas « free », dans les tableaux de bord.
Mistake 2: Capping ARC without measuring the workload
Symptômes : Bond des IOPS disque, opérations metadata ralenties, « tout semble lent » en période de pointe.
Correction : Rétablissez un cap ARC raisonnable ; mesurez les misses ARC et la latence disque.
Si vous avez besoin de marge pour les applis, cappez l’ARC sur la base d’un budget (applis + noyau + marge de sécurité), pas d’un pourcentage de « libre ».
Mistake 3: Treating ARC hit ratio as the KPI
Symptômes : On célèbre un haut hit rate alors que la latence tail est catastrophique ; ou on panique pour un faible hit rate sur des workloads streaming.
Correction : Priorisez la latence et la santé du swap. Le hit ratio est dépendant du contexte.
Un streamer média peut avoir un faible hit ratio et rester rapide ; un serveur NFS metadata-heavy, non.
Mistake 4: Enabling dedup because it “saves space”
Symptômes : Effondrement de performance soudain, lectures aléatoires élevées, pression mémoire, écritures lentes, overhead lié au DDT.
Correction : N’activez pas la dédup sans un vrai modèle capacité/performance et un budget mémoire.
Si elle est déjà activée et que vous souffrez, planifiez une stratégie de migration ; « la désactiver » n’est pas instantané sur les blocs existants.
Mistake 5: Throwing L2ARC at the problem on a RAM-tight system
Symptômes : Pas d’amélioration ou latence pire ; pression ARC augmente ; misses metadata persistent.
Correction : Assurez-vous d’avoir assez de RAM d’abord ; dimensionnez L2ARC correctement ; validez que la charge a de la réutilisation.
Si votre charge est majoritairement des lectures一次, L2ARC est un placebo coûteux.
Mistake 6: Ignoring write path issues and blaming ARC
Symptômes : Lectures lentes « parfois », mais le vrai déclencheur est des écritures sync, la latence des commits, ou un SLOG/vdev write saturé.
Correction : Mesurez bout-en-bout : zpool iostat, latence des périphériques, et patterns d’écriture applicative.
Corrigez les goulots d’écriture ; ne micro-gérez pas l’ARC pour compenser.
Mistake 7: Running mixed workloads without isolation
Symptômes : Les jobs de backup ruinent les charges interactives ; les pics de boot VM écrasent les services de fichiers ; churn du cache.
Correction : Isolez les charges par hôte, pool, ou planning. Utilisez des politiques de cache par dataset quand approprié.
Envisagez des limites cgroups mémoire pour services bruyants sous Linux.
FAQ
1) Is it bad if ZFS uses most of my RAM?
Pas en soi. C’est mauvais si le système swappe, réclame agressivement (PSI « full » élevé), ou si les applications perdent de la mémoire et ralentissent.
Si la mémoire « available » est saine et que le swap est calme, l’utilisation RAM par l’ARC est généralement une fonctionnalité.
2) Why doesn’t ARC release memory immediately when an app needs it?
L’ARC est reclaimable, mais le reclaim a une mécanique et un timing. Face à des pics soudains, l’ARC peut être en retard sur la demande,
et le noyau peut swapper avant que l’ARC ait suffisamment réduit. C’est pourquoi vous budgétisez de la marge et évitez de fonctionner au bord du gouffre.
3) Should I set zfs_arc_max on every system?
Si l’hôte exécute uniquement des charges ZFS (comme un NAS dédié), les valeurs par défaut fonctionnent souvent bien.
Si c’est un hôte d’usage mixte (bases de données, JVM, conteneurs), définir un cap peut prévenir des contentions surprises.
La bonne réponse est un budget mémoire : ce que vos applis demandent au pic, plus une marge de sécurité, plus ce que vous pouvez allouer à l’ARC.
4) What’s a “good” ARC hit ratio?
Ça dépend de la charge. Pour des lectures en streaming, un faible hit ratio peut malgré tout fournir un débit élevé.
Pour des lectures aléatoires et des charges metadata-heavy, un faible hit ratio signifie généralement de la douleur réelle.
Suivez les tendances hit/miss et corrélez avec la latence disque et la latence visible par l’utilisateur.
5) Is ARC the same as L2ARC?
Non. L’ARC est en RAM. L2ARC est un cache secondaire sur stockage rapide (SSD/NVMe). L2ARC peut étendre le caching,
mais il a besoin de RAM pour les métadonnées et n’aide pas beaucoup pour des lectures一次.
6) If I add more RAM, will ZFS always get faster?
Pas toujours, mais souvent. Plus de RAM aide quand votre working set est cacheable et que les misses sont coûteux.
Si vous êtes limité par les écritures, le CPU, le réseau, ou la conception applicative, plus d’ARC ne vous sauvera pas.
7) Why does my system show low “free” memory even when idle?
Parce que l’OS utilise la RAM pour des caches afin d’accélérer le travail futur. Les systèmes inactifs avec beaucoup de cache sont normaux.
Concentrez-vous sur la mémoire « available » et le swap, pas sur « free ».
8) Can I configure ZFS to cache only metadata?
Oui, par dataset avec primarycache=metadata. C’est utile pour des datasets avec de grands reads en streaming
qui ne tirent pas profit du cache des données, tout en gardant la traversée des répertoires et les recherches rapides.
Mesurez avant et après — cela peut se retourner contre vous si la charge réutilise réellement des données.
9) How do I tell if ARC is thrashing?
Cherchez des misses ARC soutenus durant une charge stable, une hausse d’évictions, et des pics de latence disque qui se corrèlent aux misses.
Si le système swappe aussi, vous pouvez entrer dans un cercle vicieux : la pression provoque du churn ARC, ce qui augmente les I/O, ce qui augmente la latence.
10) Why did performance drop right after a big backup or scrub?
De grandes lectures séquentielles peuvent évincer des blocs utiles en cache (surtout des métadonnées) si le cache n’est pas dimensionné ou réglé
pour des charges mixtes. La solution habituelle est la planification, l’isolation, ou la prévention de la pollution du cache — pas de réduire l’ARC définitivement.
Conclusion
L’ARC de ZFS n’est pas une fuite de mémoire déguisée en système de fichiers. C’est un choix de conception délibéré : utiliser la RAM pour éviter l’I/O disque,
et s’adapter à ce que la charge fait. L’erreur opérationnelle est de traiter la « RAM libre » comme métrique de santé et
de considérer la taille de l’ARC comme une faute morale.
Quand la performance est mauvaise, ne lancez pas de débats philosophiques — mesurez. Vérifiez la pression mémoire, le swap, les misses ARC,
la latence disque, et identifiez la charge qui a changé la donne. Ensuite décidez : capper l’ARC pour de la marge, tuner les datasets
pour éviter la pollution, isoler les charges, ou acheter plus de RAM. Le meilleur tuning ZFS est souvent le plus simple :
laissez l’ARC faire son travail, et assurez-vous que le reste du système ne la sabote pas.