ZFS arcstat : la façon la plus rapide de vérifier si le cache aide

Ce qu’est arcstat (et ce qu’il n’est pas)

arcstat est un petit script qui échantillonne les statistiques de l’ARC ZFS et les affiche comme un tableau de bord en direct. Vous le lancez, vous observez,
et vous arrêtez de deviner. Il ne « règle » rien. Il ne corrige rien. Il vous dit simplement ce que fait le cache en ce moment :
hits, misses, tailles, et parfois l’allure de votre charge de travail.

Si vous cherchez à répondre à « le cache aide-t-il ? » il y a un test brutalement honnête :
si votre taux de hit ARC est faible et que vos disques sont surchargés, le cache ne vous sauve pas.
Si votre taux de hit ARC est élevé et que les disques sont calmes, l’ARC fait le travail payé.

Le piège : les gens traitent les stats d’ARC comme une métrique de vanité. « Regardez ce taux de hit à 99% ! » Super — sur quoi ? Les métadonnées ? Des fichiers minuscules ? Des prélectures inutiles ?
Votre rôle est de mapper les chiffres au véritable goulot : latence et débit là où l’application attend réellement.

ARC en termes opérationnels simples

ARC (Adaptive Replacement Cache) est le cache en mémoire de ZFS. Ce n’est pas « un page cache ». Il concurrence le page cache de l’OS, la mémoire de votre application,
et votre calme. Il met en cache des blocs de données et des métadonnées, et il est agressif parce que le disque est lent et la RAM est rapide.

L’ARC est « adaptatif » parce qu’il essaie d’équilibrer deux classes d’objets mis en cache :
les éléments récemment utilisés et les éléments fréquemment utilisés. En pratique, cela signifie que l’ARC tente de survivre à des charges qui ruinent des caches LRU plus simples :
lectures massives en scan, charges mixtes aléatoires, et opérations de système de fichiers riches en métadonnées.

Mais l’ARC ne peut pas violer les lois de la physique. Si votre ensemble de travail ne tient pas en mémoire, votre taux de hit en pâtira. Si votre charge est principalement des lectures en streaming,
le caching peut être neutre voire nocif. Si vous êtes contraint en mémoire et que l’ARC grandit trop, vous échangerez des attentes disque contre des tempêtes d’échange —
un marché que personne ne devrait accepter.

Une citation à garder près de votre fenêtre de changement :
L’espoir n’est pas une stratégie. — Gene Kranz

Faits intéressants et historique à utiliser en réunion

• ARC n’a pas été inventé pour ZFS. L’algorithme ARC a été publié en 2003 puis adopté par ZFS parce qu’il s’adapte bien aux charges changeantes.
• Le cache de ZFS est basé sur des blocs, pas sur des fichiers. Il met en cache des blocs depuis la couche DMU, ce qui explique pourquoi les intuitions « cache de fichiers » échouent souvent.
• L’ARC met en cache les métadonnées de façon agressive. Pour de nombreux environnements (hôtes VM, serveurs de build, dépôts Git), les hits sur les métadonnées font la différence entre « ça va » et « pourquoi ls est lent ? »
• L2ARC n’est pas un cache d’écriture. C’est une extension de l’ARC sur des périphériques rapides, mais il a toujours besoin de l’ARC pour l’indexer, donc il consomme de la RAM pour utiliser « plus de cache ».
• L2ARC était auparavant volatile après un reboot. Les premières implémentations démarraient à froid ; des améliorations ultérieures ont rendu le L2ARC persistant possible dans certaines implémentations.
• ZFS a un chemin de journal d’intention séparé (ZIL/SLOG). L’ARC aide les lectures ; la latence des écritures synchrones concerne souvent le comportement du ZIL plus que l’ARC.
• La prélecture peut être un tyran silencieux pour l’ARC. Pour des charges séquentielles, la prélecture de ZFS peut remplir l’ARC avec des données que vous ne réutiliserez jamais, évincant des blocs utiles.
• La compression change les mathématiques du cache. L’ARC stocke des blocs compressés (dans de nombreuses implémentations), donc la compression peut augmenter effectivement la capacité du cache pour des données compressibles.
• Le taux de hit ARC peut sembler « bon » alors que les utilisateurs souffrent. Parce que les misses importants peuvent être sur le chemin critique (par ex. petites lectures aléatoires) alors que les hits portent sur des opérations peu coûteuses.

Blague #1 : L’ARC, c’est comme les snacks de bureau — tout le monde l’adore jusqu’à ce qu’il bouffe le budget et que quelqu’un commence à cacher des barres de céréales dans son tiroir.

Mode d’action pour diagnostic rapide (premier/deuxième/troisième)

Premier : confirmer que le système attend vraiment le stockage

Ne commencez pas par l’ARC. Commencez par « quel est le goulot ». Si le CPU est saturé, l’ARC ne vous sauvera pas. Si vous échangez, l’ARC fait partie du problème.
Si les disques sont inactifs mais que la latence est élevée, vous êtes peut‑être bloqué ailleurs (réseau, verrous, comportement mono‑thread de l’application).

Deuxième : utilisez arcstat pour classifier la charge

Regardez les hits/misses d’ARC dans le temps pendant que le problème se produit. Observez la demande de lecture et le taux de miss, pas seulement la colonne « hit% ».
Un taux de hit sans contexte est un KPI conçu pour vous rassurer.

Troisième : décidez quel réglage compte vraiment

En fonction de ce que vous trouvez :

• Si l’ARC est trop petit pour l’ensemble de travail, il vous faut plus de RAM ou modifier la charge (recordsize, primarycache, mode d’accès).
• Si l’ARC est grand mais en thrash, vous avez probablement des lectures en streaming, trop de prélecture, ou une charge qui défie le caching ; examinez le comportement applicatif et les propriétés des datasets.
• Si le taux de hit ARC est correct mais que la latence est mauvaise, arrêtez de fixer l’ARC et regardez les écritures synchrones, la fragmentation, la topologie des vdev et la profondeur des files d’attente.

Comment lire arcstat comme si vous étiez en astreinte

arcstat affiche des colonnes qui varient légèrement selon l’implémentation, mais les concepts de base restent stables :
taille du cache, taille cible, hits, misses, lectures à la demande, prélectures, et souvent des stats séparées pour les métadonnées.

Le modèle mental qui fonctionne en production :

• Les hits économisent des E/S. Les misses génèrent des E/S.
• Les lectures à la demande sont celles demandées par l’application. Les prélectures sont ZFS qui devine le futur.
• Les misses à la demande nuisent à la latence. Les misses de prélecture nuisent surtout au débit et polluent le cache.
• La taille de l’ARC devrait être stable sous charge constante. Des variations importantes signifient pression mémoire ou une charge qui fouette le cache.

Cessez d’adorer le taux de hit ; commencez à le corréler à la douleur

Un taux de hit est une fraction. Les fractions mentent par omission. Vous pouvez avoir un excellent taux de hit alors que votre application est bloquée sur les quelques misses
qui touchent une table chaude ou le pattern de lecture aléatoire d’une VM. Vous pouvez aussi avoir un taux de hit médiocre avec une latence acceptable
si les misses sont séquentielles et que vos disques peuvent les streamer efficacement.

Taille de l’ARC vs cible : qui gagne la bataille pour la RAM

L’ARC a généralement une « cible » et une « taille » courante. Si l’ARC n’atteint pas sa cible, quelque chose d’autre demande de la mémoire. Si l’ARC continue de rétrécir,
le noyau libère des pages — parfois correctement, parfois violemment. Le mode d’échec est prévisible : pression mémoire provoque éviction de l’ARC,
l’éviction augmente les E/S disque, les E/S augmentent la latence, la latence augmente l’attente en file, et vous êtes en train de dépanner la mauvaise couche.

Demande vs prélecture : le test de personnalité de votre charge

Si les hits à la demande sont élevés, l’ARC fait son travail. Si les lectures de prélecture dominent et que leurs hits sont faibles, vous mettez probablement à l’échelle des ordures.
C’est alors que vous regardez les propriétés du dataset comme primarycache, secondarycache, recordsize, et si vous devriez désactiver la prélecture pour certaines charges.
Vous ne « coupez pas la prélecture » globalement parce qu’une seule machine a passé une mauvaise journée.

Blague #2 : Activer L2ARC pour corriger une charge, c’est comme acheter un grille-pain plus rapide parce que le service du dîner est lent.

Tâches pratiques : commandes, signification des sorties et décisions

Voici des tâches réelles que j’ai utilisées pendant des incidents et des travaux de performance. Chacune a trois parties : la commande, ce que signifie la sortie,
et la décision à en tirer. Exécutez-les pendant que le problème se produit. Les moyennes historiques sont mignonnes ; les symptômes en direct paient les factures.

Task 1: Run arcstat live and identify demand vs prefetch

cr0x@server:~$ arcstat 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:01   822    61     7    34    4    27    3     2    0   42.1G  48.0G
12:01:02   910    80     9    52    6    26    3     2    0   42.2G  48.0G

Signification : read est l’activité globale de lecture ARC ; miss/miss% sont les misses globaux ; dmis/dm% sont les misses à la demande ; pmis/pm% sont les misses de prélecture ; arcsz est la taille de l’ARC ; c est la cible de l’ARC.

Décision : Si les misses à la demande sont élevés pendant une latence visible par l’utilisateur, le cache ne couvre pas l’ensemble de travail. Si les misses de prélecture dominent, vous polluez peut‑être l’ARC avec du read-ahead.

Task 2: Confirm ARC isn’t being forced to shrink (memory pressure)

cr0x@server:~$ arcstat -f time,arcsz,c,avail 1
    time   arcsz      c    avail
12:03:10  39.8G  48.0G    1.2G
12:03:11  38.9G  48.0G  900.0M
12:03:12  37.5G  48.0G  620.0M

Signification : L’ARC rétrécit pendant que la mémoire disponible s’effondre. C’est le noyau qui réclame de la RAM.

Décision : Si avail est bas et que l’ARC rétrécit, priorisez la mémoire : réduisez le maximum d’ARC, corrigez le processus qui bouffe la mémoire, ou ajoutez de la RAM. N’ajoutez pas de L2ARC ; il coûte aussi de la RAM.

Task 3: Check ARC summary counters (Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(hits|misses|demand_data_hits|demand_data_misses|prefetch_data_hits|prefetch_data_misses|size|c) '
hits                            4 231889442
misses                          4 18122344
demand_data_hits                4 168221991
demand_data_misses              4 12188511
prefetch_data_hits              4 23311233
prefetch_data_misses            4 4932100
size                            4 45188173824
c                               4 51539607552

Signification : Compteurs bruts depuis le démarrage. Utilisez‑les pour calculer des ratios et confirmer ce que montre arcstat.

Décision : Si demand_data_misses augmente rapidement pendant les incidents, corrigez l’ajustement de l’ensemble de travail (RAM, recordsize, politique de cache). Si seules les prélectures augmentent, adressez le comportement de prélecture.

Task 4: Compute demand hit ratio quickly (without lying to yourself)

cr0x@server:~$ python3 - <<'PY'
import re
d={}
for line in open("/proc/spl/kstat/zfs/arcstats"):
    m=re.match(r'^(\w+)\s+\d+\s+(\d+)$', line.strip())
    if m: d[m.group(1)]=int(m.group(2))
h=d.get("demand_data_hits",0); m=d.get("demand_data_misses",0)
print("demand_data_hit_ratio = {:.2f}%".format(100*h/(h+m) if (h+m) else 0))
PY
demand_data_hit_ratio = 93.25%

Signification : Taux de hit à la demande uniquement, en excluant le bruit de la prélecture.

Décision : Si ce taux est élevé et que vous êtes toujours lent, votre goulot n’est probablement pas le cache de lecture (pensez aux écritures synchrones, au CPU, aux verrous, au réseau).

Task 5: Verify whether you’re swapping (ARC’s favorite way to ruin your day)

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  1  10488  51200  18000 7230000   12   45   620   130 8200 9100 10  5 70 15  0
 1  1  10520  48900  17920 7215000    0   32  1110   140 7600 8800  9  4 68 19  0

Signification : si/so non nuls indiquent swap in/out ; wa est le temps d’attente d’E/S. Si vous swappez, l’ARC est en concurrence avec tout le reste.

Décision : Arrêtez d’optimiser la performance et corrigez la pression mémoire. Réduisez l’ARC, stoppez le processus gourmand en mémoire, ou montez en ressources. Swapping + ZFS, c’est une mauvaise sitcom.

Task 6: Check ZFS pool I/O and latency (are disks the real culprit?)

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
tank        9.12T  3.45T    640    210  82.1M  21.3M
  raidz2    9.12T  3.45T    640    210  82.1M  21.3M
    sda         -      -    110     36  13.8M   3.2M
    sdb         -      -    108     35  13.7M   3.1M
    sdc         -      -    107     34  13.6M   3.0M
    sdd         -      -    109     35  13.7M   3.1M

Signification : Si les disques sont saturés en opérations de lecture alors que les misses à la demande sont élevés, vous êtes limité par les E/S de lecture. Si les disques sont calmes mais que l’application est lente, l’ARC n’est pas la principale histoire.

Décision : Si les opérations de lecture saturent et que les misses ARC sont élevés : ajoutez de la RAM, ajoutez des vdevs, changez la forme de la charge, ou reconsidérez le tiering de stockage. Si les opérations d’écriture dominent : regardez les écritures sync et ZIL/SLOG.

Task 7: Check per-process I/O (catch the “one weird job”)

cr0x@server:~$ sudo iotop -oPa
Total DISK READ: 115.62 M/s | Total DISK WRITE: 22.10 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
18234 be/4   backup     98.12 M/s   1.40 M/s  0.00 % 92.00 %  /usr/bin/rsync -a --delete /data /backup
 9121 be/4   postgres   12.40 M/s  10.10 M/s  0.00 %  8.00 %  postgres: checkpointer

Signification : Un scan séquentiel ou un job de sauvegarde peut exploser l’ARC avec du read-ahead et créer des misses qui nuisent aux charges interactives.

Décision : Si un job batch domine les lectures, planifiez‑le, limitez‑le, ou isolez‑le sur un dataset avec une politique de cache différente.

Task 8: Inspect dataset caching policy (primarycache/secondarycache)

cr0x@server:~$ zfs get -o name,property,value primarycache,secondarycache tank/vmstore
NAME         PROPERTY        VALUE
tank/vmstore primarycache    all
tank/vmstore secondarycache  all

Signification : primarycache contrôle ce qui va dans l’ARC ; secondarycache contrôle ce qui va dans le L2ARC.

Décision : Pour des images VM avec comportement de streaming important, envisagez primarycache=metadata pour protéger l’ARC pour les métadonnées tout en laissant les lectures invité toucher le disque de manière prévisible.

Task 9: Change primarycache for a dataset (surgical, reversible)

cr0x@server:~$ sudo zfs set primarycache=metadata tank/backup
cr0x@server:~$ zfs get -o name,property,value primarycache tank/backup
NAME        PROPERTY      VALUE
tank/backup primarycache  metadata

Signification : Vous demandez à ZFS de mettre en cache les métadonnées mais pas les données de fichier pour ce dataset.

Décision : Utilisez ceci quand un dataset fait surtout des lectures/écritures séquentielles et que vous voulez l’empêcher d’évincer des contenus ARC utiles. Si la latence s’améliore pour d’autres charges, conservez-le. Si ça nuit aux performances du dataset, revenez en arrière.

Task 10: Check recordsize (workload fit matters more than people admit)

cr0x@server:~$ zfs get -o name,property,value recordsize tank/postgres
NAME          PROPERTY    VALUE
tank/postgres recordsize  128K

Signification : Le recordsize affecte l’amplification I/O et l’efficacité du cache. Les bases de données préfèrent souvent des blocs plus petits (ex. 16K) pour éviter de lire 128K pour satisfaire une lecture de 8K.

Décision : Si vous observez beaucoup de petites lectures aléatoires et une efficacité ARC médiocre, envisagez d’ajuster recordsize pour ce dataset (avec précaution ; cela affecte les nouvelles écritures, pas les anciennes).

Task 11: Observe prefetch behavior via ARC counters

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(prefetch_data_hits|prefetch_data_misses|demand_data_hits|demand_data_misses)'
demand_data_hits                4 168331120
demand_data_misses              4 12194410
prefetch_data_hits              4 23311610
prefetch_data_misses            4 4981044

Signification : Si les misses de prélecture augmentent rapidement pendant que les misses à la demande augmentent aussi, la prélecture peut évincer des données utiles. Si les misses de prélecture augmentent tandis que les misses à la demande restent stables, c’est peut‑être juste du débit gaspillé.

Décision : Si la prélecture semble nuisible, isolez le dataset fautif et envisagez la politique de cache ou l’ordonnancement de la charge. Ne désactivez pas la prélecture globalement à chaud.

Task 12: Check ARC sizing parameters (Linux OpenZFS)

cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_arc_max
68719476736
cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_arc_min
4294967296

Signification : ARC max/min en octets. Si le max est trop élevé par rapport à la RAM système et à la charge, vous pouvez déclencher une pression mémoire et du swap.

Décision : Si l’hôte exécute des applis qui ont besoin de RAM (bases de données, JVM, hyperviseurs VM), limitez intentionnellement l’ARC. Si l’hôte est une appliance de stockage, laissez l’ARC utiliser la plupart de la RAM mais laissez quand même une marge pour le noyau et les pics.

Task 13: Temporarily cap ARC max (careful, but effective)

cr0x@server:~$ echo $((32*1024*1024*1024)) | sudo tee /sys/module/zfs/parameters/zfs_arc_max
34359738368
cr0x@server:~$ sudo cat /sys/module/zfs/parameters/zfs_arc_max
34359738368

Signification : Vous avez réduit le maximum de l’ARC à 32 GiB. L’ARC s’adaptera progressivement ; il ne rétrécira pas instantanément jusqu’à la nouvelle limite.

Décision : Utilisez ceci quand la pression mémoire provoque du swap ou un risque d’OOM. Après application, surveillez le swap et le comportement des misses ARC. Si les misses explosent et que les disques saturent, vous avez peut‑être échangé un problème contre un autre ; reconsidérez l’architecture (plus de RAM, séparation des rôles, ajout de vdevs).

Task 14: Validate whether L2ARC is even being used

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(l2_hits|l2_misses|l2_size|l2_asize)'
l2_hits                         4 892331
l2_misses                       4 3211044
l2_size                         4 17179869184
l2_asize                        4 21474836480

Signification : Les hits/misses L2ARC montrent si votre « SSD cache » sert réellement des lectures. l2_size est la donnée stockée ; l2_asize est allouée.

Décision : Si l2_hits bouge à peine pendant la charge, le L2ARC n’aide pas. Raisons courantes : l’ensemble de travail tient déjà dans l’ARC, le dataset n’est pas éligible pour secondarycache, ou la charge est orientée écriture/streaming.

Task 15: Correlate ARC misses with real latency at the block device

cr0x@server:~$ iostat -x 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    4.01   18.55    0.00   67.32

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  svctm  %util
sda             110.0    36.0  14120   3300     9.20   68.2    2.4   35.2
sdb             108.0    35.0  14080   3200     9.10   66.7    2.3   34.8

Signification : await est le temps moyen que passent les requêtes (file + service). Un await élevé avec des misses à la demande élevés est l’image classique « le cache ne couvre pas, les disques sont en file ».

Décision : Si await monte quand les misses à la demande montent, concentrez-vous sur l’ensemble de travail de lecture, la topologie des vdev ou l’ajout d’IOPS. Si await est correct mais que la latence applicative est élevée, investiguez verrous, CPU, réseau ou écritures synchrones.

Task 16: Verify sync write behavior (because not everything is ARC)

cr0x@server:~$ zfs get -o name,property,value sync logbias tank/postgres
NAME          PROPERTY  VALUE
tank/postgres sync      standard
tank/postgres logbias   latency

Signification : Si votre problème est « les écritures sont lentes », l’ARC n’est pas votre héros. sync et logbias influencent le traitement des écritures synchrones et le comportement du ZIL.

Décision : Pour les incidents de latence d’écriture, vérifiez si la charge est sync-heavy et si vous avez un SLOG approprié. Ne maquillez pas le problème avec des mythes sur le cache.

Trois mini-histoires d’entreprise (douleur incluse)

Incident causé par une mauvaise hypothèse : « Plus d’ARC = bases de données plus rapides »

Une entreprise de taille moyenne faisait tourner un cluster PostgreSQL sur ZFS avec une belle quantité de RAM. L’équipe stockage a supposé « l’ARC doit utiliser autant de mémoire que possible. »
Ils ont augmenté zfs_arc_max et célébré un chiffre de cache plus grand sur les tableaux de bord. Une semaine plus tard, pendant la clôture de fin de mois, la latence a explosé.

L’équipe BD a accusé le stockage. Le stockage a accusé les requêtes. Tout le monde a accusé le « réseau » par habitude. Les graphiques montraient un taux de hit ARC apparemment sain.
C’était le mauvais indicateur à adorer.

Quand nous avons regardé arcstat pendant l’incident, les misses à la demande n’étaient pas catastrophiques — mais la pression mémoire l’était. La mémoire disponible a chuté,
le noyau a réclamé agressivement, et l’activité de swap a commencé. La base de données avait des shared buffers dimensionnés pour une raison, mais l’ARC s’était engouffré et forcé
l’OS à faire des choix laids. La décision « ARC plus grand » n’a pas créé plus de hits ; elle a créé un comportement mémoire moins stable.

La correction était ennuyeuse : limiter l’ARC pour laisser de la marge à la base et au noyau, puis régler la mémoire de la base intentionnellement. Les misses à la demande ont légèrement augmenté,
mais la latence s’est améliorée parce que le système a arrêté de swapper. La leçon : l’ARC n’est pas une « performance gratuite ». C’est un locataire dans votre appartement RAM,
et vous devez toujours payer le loyer aux autres locataires.

Une optimisation qui s’est retournée contre eux : « Ajoutons des SSD L2ARC partout »

Un autre service a standardisé « deux NVMes pour L2ARC » sur chaque hôte de stockage parce que quelqu’un avait lu que « le cache SSD rend ZFS rapide. »
Ils l’ont déployé comme modèle matériel. Ça avait l’air moderne. Les achats étaient contents. Les gens aiment acheter des choses brillantes.

Puis la bizarrerie : certains hôtes sont devenus plus lents sous charge mixte. Pas « un peu ». Nettement. Le cluster de traitement batch démarrait bien, puis dégringolait.
Les tableaux montraient une consommation mémoire qui montait, et le CPU avait un surcoût noyau. La latence de stockage ne s’améliorait pas toujours.

Nous avons échantillonné arcstat et vérifié les compteurs L2ARC. Les hits L2ARC étaient faibles. L’ARC servait déjà la majeure partie du set chaud en RAM.
Pendant ce temps, le système payait le coût pour alimenter et gérer le L2ARC, et utilisait de la RAM pour les en-têtes L2ARC. Sous pression, l’ARC a rétréci,
et le cache restant est devenu moins efficace. Ajouter « plus de cache » a réduit la qualité effective du cache.

La correction était encore ennuyeuse : retirer le L2ARC sur les nœuds où il n’aidait pas et le réserver à des charges spécifiques avec un profil de miss prouvé.
Nous avons aussi arrêté de traiter le L2ARC comme un paramètre par défaut et avons commencé à le traiter comme une optimisation à justifier par des mesures.
L’effet secondaire n’était pas que le L2ARC est « mauvais ». C’était que le culte du cache coûte cher.

Une pratique ennuyeuse mais correcte qui a sauvé la mise : « Mesurer pendant l’incident, pas après »

Un grand service Git interne a commencé à timeout pendant une semaine de release. Le symptôme était « lenteur aléatoire » : parfois les clones accrochaient,
parfois l’interface Web ralentissait, parfois tout semblait normal. L’astreinte a fait quelque chose de rare et correct : elle a collecté des preuves en direct
pendant que les utilisateurs hurlaient.

Ils ont lancé arcstat, zpool iostat et iotop simultanément dans une session tmux et capturé cinq minutes de sortie.
Le motif était clair. Les misses à la demande ont bondi en synchro avec un job de maintenance spécifique parcourant d’énormes arbres de répertoires.
Les disques se sont mis en file, les misses de métadonnées ont augmenté, et la latence a suivi. Rien de magique — juste une collision de charges.

Parce qu’ils avaient des données, pas des impressions, la mitigation a été propre : déplacer la fenêtre du job, isoler la politique de cache du dataset, et garder l’ARC
biaisé vers les métadonnées pour le dataset du dépôt. L’incident s’est terminé sans changement matériel, sans blâme, et sans un projet de performance de deux semaines.

La pratique n’était pas glamour. C’était simplement : collecter les bonnes stats en direct tôt, puis décider avec des preuves. C’est ainsi que vous évitez
la phrase du postmortem « nous n’avons pas pu reproduire ».

Erreurs courantes : symptôme → cause racine → correctif

1) « Le taux de hit ARC est élevé, mais les lectures restent lentes »

Symptôme : Excellent hit%, latence utilisateur toujours mauvaise.

Cause racine : Les hits sont surtout des métadonnées ou des lectures peu coûteuses ; les misses sur le chemin critique sont peu nombreux mais douloureux (petites lectures aléatoires, pages chaudes BD). Ou le goulot est écritures/CPU/réseau.

Correctif : Utilisez les stats à la demande et corrélez avec la latence disque (iostat -x) et l’I/O du pool (zpool iostat). Si les disques ne limitent pas, pivotez : écritures sync, saturation CPU, contention applicative.

2) « L’ARC rétrécit et grandit sans cesse ; les performances sont instables »

Symptôme : arcsz oscille, latence en dents de scie, parfois swap.

Cause racine : Pression mémoire. L’ARC est reclamé ; l’hôte exécute trop de choses (VMs + base + ARC) sans limites.

Correctif : Limitez l’ARC (zfs_arc_max), réduisez l’usage mémoire concurrent, ou séparez les rôles sur différents hôtes. Vérifiez que le swap est quasi nul en charge normale.

3) « Les misses de prélecture sont énormes ; l’ARC semble inutile »

Symptôme : pmis domine, le taux de hit à la demande chute pendant les scans.

Cause racine : Charge en streaming (backups, scrubs, scans) et prélecture qui ramène des données non réutilisées ; pollution du cache.

Correctif : Isolez cette charge (planifiez/la limitez), définissez primarycache=metadata sur les datasets lourds en scan, et confirmez l’amélioration des misses à la demande pour les datasets sensibles à la latence.

4) « On a ajouté L2ARC et rien n’a changé »

Symptôme : SSD cache installé, mais l2_hits n’augmente pas ; latence inchangée.

Cause racine : L’ensemble de travail tient déjà dans l’ARC ; le dataset n’est pas éligible pour secondarycache ; ou la charge est orientée écriture et non liée à des misses de lecture.

Correctif : Prouvez le besoin d’abord : misses à la demande soutenus pendant les fenêtres de charge réelle. Ensuite, assurez secondarycache=all où approprié et dimensionnez la RAM pour l’overhead des métadonnées L2ARC.

5) « Après avoir réduit l’ARC, le système est devenu plus lent »

Symptôme : Vous limitez l’ARC et la latence de lecture augmente.

Cause racine : La charge avait vraiment besoin du cache de lecture ; l’ARC masquait des disques lents. Votre limite a retiré le pansement.

Correctif : Décidez intentionnellement : ajoutez de la RAM, augmentez les vdevs/IOPS, ou changez la charge. Si l’hôte doit exécuter applis et stockage ensemble, planifiez la capacité pour que les deux puissent respirer.

6) « Charge de lecture aléatoire sur RAIDZ, c’est terrible »

Symptôme : Faible hit ARC, forte demande IOPS lecture, files d’attente, mauvaise latence.

Cause racine : Les vdevs RAIDZ ne sont pas des machines IOPS ; les petites lectures aléatoires les punissent. L’ARC ne peut pas compenser un mauvais choix d’architecture vdev.

Correctif : Ajoutez des miroirs pour les IOPS, ajoutez plus de vdevs, ou déplacez la charge vers un pool conçu pour l’I/O aléatoire. Utilisez l’ARC pour aider, pas pour compenser l’architecture.

7) « Nous avons réglé recordsize et maintenant le cache semble pire »

Symptôme : Après avoir changé recordsize, le taux de hit bouge de façon inattendue ; performances mitigées.

Cause racine : Le recordsize n’affecte que les nouvelles écritures ; les anciennes données restent avec l’ancienne taille de bloc. Vous avez maintenant un format disque mixte et des stats confuses.

Correctif : Évaluez sur les données écrites après le changement, ou réécrivez les données (si approprié). Évitez les changements de recordsize sans plan de migration et cible de charge claire.

Listes de contrôle / plan étape par étape

Checklist A: « L’ARC aide-t-il en ce moment ? » (5 minutes)

1. Lancez arcstat 1 et surveillez les misses à la demande et la stabilité de la taille de l’ARC.
2. Exécutez zpool iostat -v 1 pour voir si les vdevs sont saturés.
3. Exécutez iostat -x 1 pour vérifier await et la profondeur de file.
4. Si les misses à la demande sont faibles et les disques calmes : arrêtez d’accuser le cache.
5. Si les misses à la demande sont élevés et les disques en file : le cache ne couvre pas ; planifiez RAM/vdev/changes de charge.

Checklist B: « L’ARC cause-t-il des problèmes ? » (triage pression mémoire)

1. Vérifiez vmstat 1 pour le swap (si/so).
2. Vérifiez arcstat -f arcsz,c,avail 1 pour un ARC qui rétrécit et une mémoire disponible faible.
3. Si swap ou avail sont persistants bas : limitez l’ARC et/ou réduisez la pression mémoire applicative.
4. Après les changements, confirmez que le swap reste calme et que les misses à la demande n’ont pas explosé.

Checklist C: « Devons‑nous ajouter du L2ARC ? » (n’achetez pas du matériel sur des impressions)

1. Prouvez des misses à la demande soutenus pendant des fenêtres de charge réelles.
2. Prouvez que les disques sont en lecture‑saturation (ops et latence) quand ces misses se produisent.
3. Confirmez que la charge a des re‑lectures (pas un flux en une passe).
4. Confirmez que vous avez de la marge RAM pour l’overhead L2ARC et l’indexation.
5. Déployez sur un hôte, mesurez la croissance de l2_hits et l’impact sur la latence, puis scalez.

Checklist D: « Modifier un dataset en toute sécurité »

1. Identifiez le dataset qui pollue (depuis iotop + chronologie + comportement arcstat).
2. Ajustez primarycache ou recordsize uniquement sur ce dataset, pas globalement.
3. Documentez la baseline : cinq minutes d’arcstat, zpool iostat, iostat -x.
4. Appliquez le changement, re‑mesurez pendant la même fenêtre de charge.
5. Si c’est pire, revenez en arrière immédiatement. Laissez votre ego de côté.

FAQ

1) Quel est le seul chiffre arcstat que je devrais surveiller ?

Les misses à la demande pendant la fenêtre du problème. Pas le hit% global. Si les misses à la demande montent et que la latence disque augmente avec eux, le cache ne couvre pas.

2) Un taux de hit ARC de 90–95% est‑il « bon » ?

Peut‑être. Cela dépend de ce qui est en hit. Un taux de hit élevé avec une mauvaise latence signifie souvent que les misses sont sur le chemin critique, ou que le problème n’est pas du tout lié au cache de lecture.

3) Pourquoi les misses de prélecture sont‑ils si élevés, et dois‑je paniquer ?

Les misses de prélecture peuvent être élevés sur des charges séquentielles. Paniquez seulement si l’activité de prélecture se corrèle avec l’éviction de données utiles de l’ARC et la latence visible par les utilisateurs.

4) L’ARC met‑il en cache les écritures ?

L’ARC est principalement un cache de lecture. Les écritures passent par des transaction groups et peuvent être tamponnées en mémoire, mais les plaintes sur la latence d’écriture concernent souvent les écritures synchrones et ZIL/SLOG, pas l’ARC.

5) Si j’ajoute de la RAM, les performances s’amélioreront‑elles toujours ?

Si vous êtes limité par des misses de lecture et que votre ensemble de travail est mis en cache, oui — souvent de façon spectaculaire. Si vous êtes limité par des écritures synchrones, le CPU ou le réseau, la RAM ne vous sauvera pas.

6) Quand le L2ARC aide‑t‑il réellement ?

Quand vous avez une charge en lecture avec un ensemble de travail plus grand que la RAM mais avec des relires significatives, et que vos disques sont le goulot. L2ARC n’est pas un accélérateur universel.

7) Pourquoi mon système est‑il devenu plus lent après l’ajout de L2ARC ?

Parce que le L2ARC consomme de la RAM pour les métadonnées et ajoute du travail de gestion. Si l’ARC était déjà suffisant, vous avez payé un coût sans bénéfice et possiblement augmenté la pression mémoire.

8) Dois‑je mettre primarycache=metadata pour les images VM ?

Souvent une bonne idée quand les VM font beaucoup de lectures en streaming qui churnent le cache. Testez‑le sur un sous‑ensemble d’abord ; certains workloads VM bénéficient du caching des données.

9) La compression améliore‑t‑elle l’efficacité de l’ARC ?

Souvent, oui, car les blocs mis en cache peuvent être stockés compressés, ce qui permet d’inscrire plus de données logiques dans la même RAM. Mais la compression coûte aussi du CPU — mesurez les deux côtés.

10) Pourquoi arcstat semble différent selon les systèmes ?

Différentes distributions et scripts affichent des colonnes et des noms différents. Les concepts sous‑jacents — hits, misses, taille ARC, demande vs prélecture — sont ce à quoi vous devez vous raccrocher.

Conclusion : prochaines étapes qui aident vraiment

Si vous ne retenez qu’une habitude : lancez arcstat pendant l’incident, pas après. Associez‑le à zpool iostat et iostat -x.
En dix minutes vous pouvez généralement répondre à la seule question qui compte : « Sommes‑nous bloqués sur des lectures disque que le cache aurait pu servir ? »

Prochaines étapes pratiques :

1. Capturez une baseline de cinq minutes pendant la charge normale : arcstat + zpool iostat + iostat -x.
2. Pendant le prochain ralentissement, capturez le même trio et comparez les misses à la demande et la latence disque.
3. Si la pression mémoire existe, limitez l’ARC intentionnellement et éliminez le swap en priorité.
4. Si les misses à la demande sont le facteur limitant, choisissez : ajouter de la RAM, repenser la topologie vdev pour les IOPS, ou changer le comportement de cache des datasets/charges.
5. Si l’ARC semble sain, arrêtez d’optimiser le cache et cherchez le vrai goulot (écritures sync, CPU, réseau, verrous).

Le cache n’est pas une stratégie de performance. C’est un multiplicateur de performance — utilisez‑le quand le calcul est favorable, ignorez‑le quand il ne l’est pas, et mesurez sérieusement.