ARC ZFS par To : dimensionner la RAM sans mythes ni religion de forum

Arrêtez d’utiliser « RAM par To » comme règle de dimensionnement

« 1 Go de RAM par To de stockage » est l’équivalent stockage de « redémarrez et voyez si ça aide. » Parfois ça marche par accident, c’est pourquoi ça survit.
Mais ce n’est pas une méthode de dimensionnement. C’est une superstition avec une unité attachée.

L’ARC ZFS est un cache. Les caches ne se dimensionnent pas à la capacité ; ils se dimensionnent au working set et aux objectifs de latence.
Votre pool peut être 20 To d’archives froides écrites une fois et jamais lues. Ou il peut être 20 To de VM effectuant des lectures aléatoires 4K avec un petit hot set qui tient en mémoire.
Ces deux mondes ont les mêmes « To » et des « RAM pertinentes » radicalement différentes.

Voici ce que la règle par téraoctet manque :

• Le schéma d’accès prime sur la capacité. Les scans séquentiels peuvent balayer n’importe quelle taille d’ARC ; les lectures aléatoires peuvent être transformées par l’ARC.
• Les métadonnées ont une valeur différente des données. Cacher les métadonnées peut rendre un « disque lent » acceptable sans mettre en cache beaucoup de données utilisateur.
• ZFS a des réglages qui changent le comportement mémoire. recordsize, compression, special vdevs, dnodesize et primarycache comptent.
• L’ARC entre en compétition avec vos applications. La meilleure taille d’ARC est celle qui n’affame pas la charge réelle.

Ce que vous devriez faire à la place est ennuyeux : choisissez un objectif de performance, observez le comportement du cache, validez votre working set, et dimensionnez la RAM pour atteindre l’objectif.
Si vous achetez du matériel, faites-le avec un plan et une possibilité de retour arrière.

Blague n°1 : Si vous dimensionnez l’ARC par téraoctets, vous finirez par acheter un serveur qui est essentiellement un radiateur avec des ports SATA.

ARC : ce que c’est, et ce que ce n’est pas

ARC est un cache résidant en mémoire avec conscience de la pression mémoire

L’ARC (Adaptive Replacement Cache) vit en RAM. Il met en cache à la fois les données et les métadonnées, et il est conçu pour s’adapter entre
les schémas « récemment utilisés » et « fréquemment utilisés ». Cette partie « adaptive » est réelle : l’ARC suit plusieurs listes et utilise des entrées ghost
pour apprendre ce qu’il aurait souhaité avoir en cache.

L’ARC est aussi censé jouer raisonnablement avec l’OS lorsque la pression mémoire augmente. Sur Linux, l’ARC se réduit en fonction de zfs_arc_max
et des signaux de pression ; sur FreeBSD c’est intégré différemment mais vise toujours à éviter l’étouffement total. « Censé » a son importance :
vous devez vérifier que votre version d’OS et de ZFS se comporte correctement dans votre environnement.

ARC n’est pas « comment ZFS garde votre pool cohérent »

La cohérence ZFS provient du copy-on-write, des transaction groups et du journal d’intention (ZIL/SLOG pour le comportement synchrone). Rien de tout cela n’exige un ARC massif.
Oui, ZFS utilise de la mémoire pour les métadonnées et la comptabilité, mais le mythe « ZFS a besoin de tonnes de RAM pour ne pas corrompre vos données » est absurde dans les versions modernes.
Vous pouvez exécuter ZFS avec une RAM modeste et il restera correct. Il sera juste peut‑être plus lent.

ARC n’est pas un substitut à une mauvaise conception d’E/S

Si votre charge est 90 % d’écritures synchrones sur un pool de disques lents et que vous n’avez pas un SLOG approprié, doubler l’ARC ne vous sauvera pas.
Si votre goulot d’étranglement est le CPU (compression, checksums, chiffrement) ou une application mono-thread, l’ARC ne vous sauvera pas.
Si votre pool est rempli à 90 % et fragmenté, l’ARC ne vous sauvera pas non plus. L’ARC est un cache, pas un thérapeute.

Le contenu de l’ARC est façonné par les propriétés des datasets

Le caching ZFS n’est pas monolithique. Les propriétés du dataset influencent ce qui est mis en cache et la gravité des misses :

• recordsize change l’amplification I/O et la granularité des blocs mis en cache.
• primarycache peut être réglé sur all, metadata ou none.
• compression change la quantité de données « logiques » par octet d’ARC et impacte le CPU.
• atime et le churn des métadonnées peuvent transformer des lectures en pression d’écritures.

Une citation, parce qu’elle reste la meilleure formulation :
L’espoir n’est pas une stratégie. — James Cameron

Dimensionnement centré sur la charge : le seul modèle qui tient en production

Étape 1 : classifiez la charge que vous exécutez réellement

« Serveur de fichiers » n’est pas une description de charge. Il vous faut au minimum ce niveau de détail :

• Type d’E/S : majoritairement lectures, majoritairement écritures, mixte.
• Sémantique des écritures : sync-heavy (bases de données, NFS en sync), async-heavy (ingest massif).
• Schéma d’accès : aléatoire 4K/8K, séquentiel, beaucoup de petits fichiers, gros fichiers en streaming.
• Hot set : approximativement combien de données sont touchées de manière répétée par heure/jour.
• Objectif de latence : « Les VM semblent réactives » n’est pas un objectif ; « p95 lecture < 5 ms » l’est.

Étape 2 : décidez ce que vous voulez que l’ARC fasse

L’ARC peut apporter de la valeur de trois façons courantes :

1. Accélérer les lectures aléatoires en servant les blocks chauds depuis la RAM.
2. Accélérer les métadonnées (parcours de répertoires, ouverture de fichiers, petits fichiers, navigation de snapshots).
3. Réduire les seeks disque en transformant des lectures répétées en hits mémoire, libérant les disques pour les écritures.

Le troisième point est sous-estimé : parfois vous êtes « lent pour écrire » parce que les disques sont occupés à faire des lectures évitables.
L’ARC peut indirectement accélérer les écritures en supprimant la pression de lecture.

Étape 3 : choisissez un point de départ volontairement conservateur

Baseline pratique (pas par To, et pas une loi) :

• Petit hôte de VM / petit NAS : 16–32 Go de RAM, puis validez.
• Nœud de virtualisation général avec pool SSD : 64–128 Go de RAM si vous attendez de la localité de lecture.
• Grands pools HDD servant des charges actives : priorisez le cache de métadonnées et envisagez des special vdevs ; la RAM seule peut ne pas suffire.
• Bases de données avec écritures synchrones : l’ARC aide les lectures ; pour les écritures privilégiez SLOG et topologie du pool en premier.

Si vous ne pouvez pas expliquer ce que l’ARC mettra en cache et pourquoi cela compte, n’achetez pas encore la RAM. Mesurez d’abord.

Étape 4 : comprenez pourquoi « plus d’ARC » peut nuire

Un ARC plus grand n’est pas gratuit :

• Pression mémoire peut pousser l’OS au swap ou à des tempêtes de reclaim. Si votre hyperviseur swap, votre « cache » devient une panne au ralenti.
• Temps de chauffe augmente après reboots ou basculements. Un ARC énorme signifie plus de temps pour atteindre l’état stable.
• Pollution du cache provenant de scans/sauvegardes peut expulser ce qui compte vraiment, surtout si vous autorisez la mise en cache de toutes les données.
• Contraintes de mémoire noyau et fragmentation peuvent devenir votre nouveau problème étrange.

Un modèle mental utilisable : « hot set + métadonnées + marge de sécurité »

Le dimensionnement d’ARC qui ne vous couvre pas de ridicule en postmortem suit généralement cette logique :

• Estimer le hot data set : la portion de données lues de manière répétée dans votre fenêtre de latence.
• Ajouter une réserve pour les métadonnées : entrées de répertoire, blocs indirects, dnodes, objets ZAP. Très dépendant de la charge.
• Laisser de la mémoire pour l’OS et les applis : page cache (si applicable), overhead hyperviseur, conteneurs, bases de données, agents de monitoring, et le « truc que vous avez oublié ».
• Limiter l’ARC : ne le laissez pas « gagner » à chaque fois. Votre application paie la note.

Faits et historique intéressants (parce que les mythes ont des histoires d’origine)

• ARC précède l’adoption de ZFS sur Linux de plusieurs années. L’algorithme ARC a été décrit en milieu académique (IBM) avant que ZFS ne le rende célèbre dans le monde du stockage.
• La règle « 1 Go par To » a probablement commencé comme un avertissement grossier pour des pools riches en métadonnées. Les premières mises en œuvre avec de grands répertoires sur disques lents étaient pénibles sans assez de RAM.
• Les premières versions de ZFS étaient plus gourmandes en mémoire et moins configurables. OpenZFS moderne a amélioré la comptabilité mémoire et ajouté des réglages comme L2ARC persistant et special vdevs.
• L2ARC n’était pas persistant au reboot à l’origine. Cela le rendait moins utile pour les systèmes qui redémarraient souvent ; L2ARC persistant a changé l’économie pour certaines équipes.
• ZIL et SLOG sont souvent mal compris comme « cache d’écritures ». Ils concernent les sémantiques synchrones, pas l’accélération de toutes les écritures. Cette confusion alimente de mauvaises décisions RAM.
• Les valeurs par défaut de recordsize ont été choisies pour les fichiers généraux, pas pour les VM. Un recordsize par défaut comme 128K avait du sens historiquement, mais les charges d’E/S aléatoires demandent souvent un réglage différent.
• Les special vdevs ont été introduits pour résoudre une douleur spécifique. Mettre les métadonnées (et éventuellement les petits blocs) sur SSD peut surpasser le simple « ajouter de la RAM » sur des pools HDD.
• La compression est devenue une recommandation par défaut parce que le CPU est devenu bon marché. Avec des CPUs modernes, la compression peut augmenter l’ARC effectif et réduire les I/O—jusqu’à ce qu’elle devienne votre goulot d’étranglement.

Feuille de route pour un diagnostic rapide

Quand quelqu’un dit « ZFS est lent », vous avez environ cinq minutes pour éviter une heure de spéculation. Voici l’ordre qui a tendance à rapporter.

Premier : décidez si le goulot est lecture, écriture ou latence liée au sync

• Vérifiez l’I/O et la latence du pool (les disques sont-ils saturés, y a-t-il des ops en attente ?).
• Vérifiez si les écritures sync dominent (NFS sync, fsync de base de données).
• Vérifiez si vous observez des misses de cache ou du thrash dans le cache.

Second : vérifiez la pression mémoire et le comportement de l’ARC

• L’OS swappe-t-il ou fait-il du reclaim agressif ?
• L’ARC est-il près de son maximum et affiche-t-il beaucoup de misses ?
• L’ARC se réduit-il à cause de la pression ?

Troisième : cherchez les pièges de configuration classiques

• Pool trop plein, fragmentation et topologie vdev HDD lent.
• Mauvais recordsize pour la charge.
• Backups/scrubs/resilver en collision avec les pics de charge.
• Abus de L2ARC (cache SSD énorme avec trop peu de RAM).

Quatrième : seulement alors parlez d’acheter de la RAM

Si le pool est limité en IOPS et que vous avez un hot set stable, l’ARC aide. Si le pool est limité par les écritures synchrones, réparez SLOG/topologie.
Si le pool est limité par le CPU, réparez le CPU. Si le pool est « rempli à 92 % », réglez la capacité.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ce sont des tâches de terrain. Elles ne sont pas théoriques. Exécutez-les, lisez les sorties, et prenez une décision.
Les commandes supposent OpenZFS sur Linux avec les outils habituels ; adaptez selon votre distro.

Task 1: Check basic memory pressure (swapping kills more ZFS “performance” than any ARC setting)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        79Gi       3.2Gi       1.1Gi        42Gi        44Gi
Swap:          8.0Gi       2.6Gi       5.4Gi

Ce que ça signifie : Le swap est utilisé. Ce n’est pas forcément la preuve d’un incident, mais c’est un signal.
Décision : Si le swap croît pendant la charge ou les pics de latence, limitez l’ARC et/ou ajoutez de la RAM après avoir confirmé que la charge a besoin de cache.

Task 2: Identify whether the kernel is thrashing on reclaim

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
 3  0 270336 3421120  91264 41277440   0   0   120   250 5400 7200 12  6 78  4  0
 5  1 270336 2897408  91264 41300224   0  64    90  1800 6100 9100 18 10 55 17  0
 6  2 271360 2019328  91264 41311232   0 512    60  4200 6900 9800 15 11 42 32  0

Ce que ça signifie : so (swap out) augmente et wa (I/O wait) est élevé. Vous payez la pression mémoire par une latence disque.
Décision : Réduisez zfs_arc_max (ou corrigez le vrai consommateur de mémoire) avant toute autre action. ZFS ne peut pas mettre efficacement en cache quand l’OS l’évince.

Task 3: Confirm ARC size and whether it’s pinned near max

cr0x@server:~$ arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:01:10   820    96     11    12    1    84   10     0    0   88.2G  92.0G
12:01:11   901   210     23    18    2   192   21     0    0   88.3G  92.0G
12:01:12   870   245     28    20    2   225   26     0    0   88.3G  92.0G

Ce que ça signifie : La taille de l’ARC (arcsz) est proche de la cible (c) et le miss% augmente.
Décision : Si c’est en état stable et que la charge est lecture-dominante, ajouter de la RAM peut aider. Si miss% monte pendant des sauvegardes/scans, corrigez la pollution du cache d’abord.

Task 4: Look at detailed ARC breakdown (metadata vs data, and whether you’re paying for it)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|hits|misses|mfu_hits|mru_hits|metadata_size|data_size) '
size                            94701989888
c_min                           4294967296
c_max                           103079215104
hits                            182993948
misses                          23120291
mfu_hits                        119002331
mru_hits                        56211617
metadata_size                   22811942912
data_size                       70100215808

Ce que ça signifie : Vous mettez en cache beaucoup de métadonnées (~22 Go) et beaucoup de données (~70 Go). Les hits dépassent largement les misses globalement.
Décision : Si la latence reste mauvaise, votre problème peut ne pas être le cache de lecture. Passez à la latence du pool et aux vérifications d’écritures sync.

Task 5: Check pool health and obvious vdev layout constraints

cr0x@server:~$ zpool status -v
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:33 with 0 errors on Sun Dec 22 03:10:19 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0

errors: No known data errors

Ce que ça signifie : Un vdev RAIDZ2 se comporte comme un unique vdev pour les IOPS. Excellent pour la capacité et le débit séquentiel, pas pour les IOPS aléatoires.
Décision : Si la charge est I/O aléatoire (VMs), n’essayez pas de « résoudre ça avec l’ARC ». Ajoutez des vdevs, utilisez des miroirs, ou déplacez les charges chaudes sur SSD.

Task 6: Check pool fullness (performance cliff is real)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  78.3T  4.1T   192K   /tank

Ce que ça signifie : Le pool est effectivement utilisé à ~95 %. L’allocation devient coûteuse ; la fragmentation et le comportement des metaslabs deviennent problématiques.
Décision : Arrêtez de débattre ARC. Ajoutez de la capacité ou supprimez/migrez des données. Puis réévaluez les performances.

Task 7: Spot sync write pressure (the “why are my writes slow?” trap)

cr0x@server:~$ zfs get -o name,property,value -s local,received sync tank
NAME  PROPERTY  VALUE
tank  sync      standard

Ce que ça signifie : Le comportement sync est par défaut. Les applis qui appellent fsync ou les clients qui exigent le sync forcent le comportement ZIL.
Décision : Si vous exécutez une base de données ou NFS avec une charge sync-heavy, investiguez le SLOG et la latence, pas la taille de l’ARC.

Task 8: Check whether you even have a SLOG device and what it is

cr0x@server:~$ zpool list -v tank
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank        83.6T  78.3T  5.3T        -         -    41%    93%  1.00x  ONLINE  -
  raidz2-0  83.6T  78.3T  5.3T        -         -    41%  93.6%      -      -  -

Ce que ça signifie : Aucun log vdev listé. Les écritures sync atterrissent sur le pool principal.
Décision : Si la latence d’écritures sync est la douleur, un SLOG basse latence approprié (protections contre la perte d’alimentation) peut aider plus qu’une montée de RAM.

Task 9: Measure real-time pool I/O and latency

cr0x@server:~$ zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        78.3T  5.3T   1200    980   210M  145M
  raidz2-0  78.3T  5.3T   1200    980   210M  145M
    sda         -      -    210    160  35.0M  23.5M
    sdb         -      -    195    165  33.1M  24.0M
    sdc         -      -    205    155  34.2M  22.8M
    sdd         -      -    180    170  30.8M  25.1M
    sde         -      -    195    165  33.0M  24.0M
    sdf         -      -    215    165  34.9M  23.9M
----------  -----  -----  -----  -----  -----  -----

Ce que ça signifie : Le pool effectue beaucoup d’opérations. Si ce sont de petites I/O aléatoires sur HDD, la latence est probablement élevée même si le débit semble correct.
Décision : Si les ops sont élevées et la charge sensible à la latence, envisagez des miroirs/plus de vdevs/une hiérarchisation SSD avant d’acheter de la RAM.

Task 10: Check dataset properties that directly affect ARC efficiency

cr0x@server:~$ zfs get -o name,property,value recordsize,compression,atime,primarycache tank/vmstore
NAME         PROPERTY      VALUE
tank/vmstore recordsize    128K
tank/vmstore compression   lz4
tank/vmstore atime         on
tank/vmstore primarycache  all

Ce que ça signifie : recordsize 128K et atime=on pour un store de VM est un auto-sabotage courant. atime ajoute des écritures ; de gros enregistrements gonflent l’I/O aléatoire.
Décision : Envisagez atime=off et un recordsize adapté aux VM (souvent 16K) après tests. Si le hot set est petit, l’ARC se comportera aussi mieux.

Task 11: See if compression is helping or hurting (and whether CPU is the real bottleneck)

cr0x@server:~$ zfs get -o name,property,value compressratio tank/vmstore
NAME         PROPERTY       VALUE
tank/vmstore compressratio  1.62x

Ce que ça signifie : La compression est efficace : 1.62x signifie que vous économisez de l’I/O et que vous logez plus de données logiques dans l’ARC.
Décision : Conservez-la sauf si le CPU est saturé. Si le CPU est saturé, la compression peut être le goulot et plus de RAM ne résoudra rien.

Task 12: Verify CPU saturation during “slow storage” complaints

cr0x@server:~$ mpstat -P ALL 1 2
Linux 6.8.0 (server)  12/26/2025  _x86_64_  (32 CPU)

12:05:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %guest  %gnice  %idle
12:05:02 PM  all   58.2    0.0   18.9     1.1   0.0    0.8     0.0     0.0     0.0   21.0
12:05:02 PM   7    96.0    0.0    3.8     0.0   0.0    0.0     0.0     0.0     0.0    0.2

Ce que ça signifie : Un CPU est presque saturé. Cela peut être un thread unique occupé (checksums, compression, une VM, un chemin d’interruption).
Décision : Si la latence du stockage se corrèle avec la saturation CPU, ajouter de l’ARC ne servira à rien. Cherchez les hotspots CPU et répartissez la charge.

Task 13: Check L2ARC presence and whether it’s reasonable for your RAM

cr0x@server:~$ zpool status tank | egrep -A3 'cache|special|logs'
        cache
          nvme1n1p1               ONLINE       0     0     0

Ce que ça signifie : Vous avez un périphérique L2ARC. L2ARC n’est pas magique ; il consomme des ressources ARC pour les headers et les métadonnées et peut augmenter l’amplification de lecture.
Décision : Si la RAM est petite et le L2ARC grand, vous pouvez devenir plus lent. Validez via les stats ARC/L2ARC avant de supposer que ça aide.

Task 14: Check whether ARC is dominated by metadata (a hint that metadata acceleration is the goal)

cr0x@server:~$ arc_summary | egrep 'ARC Size|Most Recently Used|Most Frequently Used|Metadata Size|Data Size'
ARC Size:                                88.3 GiB
Most Recently Used Cache Size:           31.2 GiB
Most Frequently Used Cache Size:         56.1 GiB
Metadata Size:                           21.3 GiB
Data Size:                               65.8 GiB

Ce que ça signifie : Une portion significative est des métadonnées. C’est bon quand votre charge est « beaucoup de fichiers », snapshots, et parcours de répertoires.
Décision : Si les métadonnées sont le problème et que vous êtes sur HDD, envisagez des special vdevs pour les métadonnées avant de jeter de la RAM indéfiniment.

Task 15: Find cache pollution culprits (sequential readers flattening your ARC)

cr0x@server:~$ iotop -oPa
Total DISK READ:         422.31 M/s | Total DISK WRITE:         12.05 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN  IO>    COMMAND
18322 be/4  backup    410.12 M/s    0.00 B/s  0.00 %  92.14 % tar -cf - /tank/vmstore | ...

Ce que ça signifie : Un job de sauvegarde stream des lectures. Cela peut évincer du contenu utile du cache à moins d’être géré.
Décision : Envisagez de régler primarycache=metadata sur les datasets de sauvegarde, d’utiliser send/receive de snapshots, ou de planifier/limiter l’I/O des sauvegardes.

Task 16: Confirm your ARC cap and adjust safely (temporary test)

cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_max
103079215104

cr0x@server:~$ echo 68719476736 | sudo tee /sys/module/zfs/parameters/zfs_arc_max
68719476736

Ce que ça signifie : Vous avez réduit zfs_arc_max à 64 Gio (la valeur est en octets). C’est un changement en direct dans beaucoup de setups.
Décision : Si la latence applicative s’améliore (moins de swap, moins de reclaim), conservez une cap plus bas. Si la latence de lecture se dégrade et que la pression mémoire reste correcte, augmentez la RAM à la place.

Blague n°2 : L2ARC est comme un second congélateur—utile, jusqu’à ce que vous réalisiez que vous l’avez acheté parce que vous avez oublié comment fonctionnent les courses.

Trois mini-récits d’entreprise (comment ça foire en vrai)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (« RAM par To » comme spécification d’achat)

Une entreprise de taille moyenne a renouvelé ses nœuds de stockage pour un cloud privé. Le RFP spécifiait littéralement la mémoire comme « 1 Go par To utilisable ».
Personne n’a contesté parce que ça sonnait technique et venait avec un chiffre. Les achats aiment les chiffres.

Les nouveaux nœuds sont arrivés avec beaucoup de disques et une quantité respectable de RAM—selon la règle par To. Le problème : la charge était composée de VM,
principalement des lectures/écritures aléatoires, hébergées sur une paire de larges vdevs RAIDZ2 par nœud. Le hot working set était petit et en rafales, et le vrai limiteur
était les IOPS d’écriture aléatoire et la latence pendant les tempêtes de snapshot.

En une semaine, les tickets s’amoncelèrent : « Les VM se figent », « Timeouts base de données », « les graphes de stockage semblent corrects ». Les graphes semblaient corrects parce qu’ils étaient des graphes de bande passante.
La latence était le tueur, et ZFS faisait exactement ce qu’on attend : il ne pouvait pas faire apparaître des IOPS de nulle part sur des vdevs RAIDZ larges sous charge aléatoire.

Le postmortem fut embarrassant. Plus de RAM aurait aidé certaines lectures, certes. Mais l’incident était provoqué par la latence d’écriture et la topologie des vdevs.
La solution n’était pas « doubler la mémoire ». C’était « arrêter de mettre des charges VM I/O aléatoire sur un petit nombre de RAIDZ larges » et « séparer les charges par classe de performance ».

La leçon : une règle de dimensionnement qui ignore les IOPS est une responsabilité. « RAM par To » ne dit rien de ce qui blesse généralement en premier.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (L2ARC partout, parce que les SSD sont bon marché)

Un autre atelier gérait une flotte de nœuds de virtualisation supportés par ZFS. Quelqu’un a fait le calcul : les NVMe étaient peu coûteux,
donc ils ont ajouté des périphériques L2ARC à chaque nœud. Plus grand cache, lectures plus rapides. Le changement a été mergé avec un joli résumé Jira et zéro mesure.

En quelques jours, la latence de lecture s’est aggravée sous charge. Pas catastrophiquement, mais suffisamment pour irriter les clients et provoquer des secousses périodiques.
L’équipe a d’abord blâmé le réseau, puis l’hyperviseur, puis « l’overhead ZFS ».

Le vrai problème était prévisible : les nœuds n’avaient pas assez de RAM pour supporter efficacement le L2ARC. L2ARC consomme des ressources ARC pour les en-têtes et les métadonnées,
et change le pattern I/O. Les périphériques cache étaient grands par rapport à la RAM, ce qui augmentait le churn et l’overhead tout en ne retenant pas les bonnes données chaudes.
Sous charge mixte, ils payaient un travail supplémentaire pour des misses.

Le rollback du L2ARC sur certains nœuds améliora immédiatement la stabilité. Plus tard, ils réintroduisirent L2ARC uniquement sur les nœuds avec assez de RAM et sur des charges
ayant une localité confirmée dépassant l’ARC mais bénéficiant d’un cache de second niveau.

La leçon : « cache SSD » n’est pas automatiquement bon. Si vous ne connaissez pas vos types de miss et votre working set, vous n’ajoutez qu’un autre élément mobile
qui peut vous décevoir à échéance.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (cap ARC + discipline de changement)

Une équipe gérait un service de fichiers ZFS pour des builds internes et des artefacts. Pendant une release chargée, le service commença à timeout.
Le premier intervenant remarqua une activité de swap et des tempêtes de reclaim mémoire. Classique.

Ils avaient un runbook ennuyeux : « Vérifiez la pression mémoire ; cappez l’ARC temporairement ; validez la récupération applicative ; puis ajustez définitivement. »
Pas d’héroïsme, pas de navigation sur les forums. Ils réduisirent zfs_arc_max en direct, libérant de la mémoire pour les services qui échouaient réellement.

La latence chuta en quelques minutes. Pas parce que l’ARC était mauvais, mais parce que le système avait dérivé : nouveaux agents, plus de conteneurs, et une charge de build plus importante
consommaient la mémoire. L’ARC faisait son travail—utiliser ce qu’il pouvait—jusqu’à ce que l’OS commence à swapper.

La correction permanente n’était pas « désactiver l’ARC ». C’était fixer un cap raisonnable pour l’ARC, augmenter la RAM au cycle matériel suivant, et ajouter du monitoring
qui alerte sur le swap et les événements de shrink de l’ARC. Le service survécut à la release sans autre incident.

La leçon : les garde-fous ennuyeux battent les suppositions ingénieuses. L’ARC est puissant, mais il ne doit jamais affamer votre logique métier.

Erreurs courantes : symptôme → cause racine → correctif

1) « ZFS est lent après qu’on ait ajouté plus de disques »

Symptôme : Plus de capacité, latence pire ; les graphes de bande passante semblent ok.

Cause racine : La nouvelle topologie vdev a augmenté l’overhead de parité ou a élargi le RAIDZ sans ajouter d’IOPS ; la fragmentation s’est aggravée ; le pool est maintenant trop plein.

Fix : Vérifiez zpool iostat et le remplissage du pool ; ajoutez des vdevs (IOPS), pas seulement des disques (capacité). Gardez l’utilisation du pool sous contrôle.

2) « Le taux de hit ARC est élevé, mais les applis timeoutent toujours »

Symptôme : Hit% ARC correct ; pics de latence persistants.

Cause racine : Latence d’écritures sync (ZIL/SLOG), saturation CPU, ou un vdev lent unique ; l’ARC ne corrige pas les sémantiques d’écriture synchrone.

Fix : Mesurez le comportement sync ; validez le SLOG ; vérifiez le CPU et la latence par vdev. Résolvez le vrai goulot.

3) « On a ajouté L2ARC et tout s’est aggravé »

Symptôme : Latence de lecture plus élevée et plus de jitter après l’ajout de SSD cache.

Cause racine : L2ARC trop grand par rapport à la RAM ; overhead augmenté ; churn du cache ; mauvaise charge (pas de localité).

Fix : Supprimez ou réduisez le L2ARC ; assurez-vous d’avoir suffisamment de RAM ; confirmez le bénéfice avec les statistiques de miss avant de le réintroduire.

4) « Les VMs bégayent pendant les sauvegardes »

Symptôme : Chutes de performance prévisibles pendant les fenêtres de sauvegarde.

Cause racine : Lectures séquentielles qui polluent l’ARC et concurrencent les disques ; scrub/resilver en collision avec l’I/O de production.

Fix : Limitez l’I/O des sauvegardes, séparez les datasets, utilisez primarycache=metadata où approprié, planifiez les scrubs avec soin.

5) « On a plein de RAM ; pourquoi l’ARC n’est pas énorme ? »

Symptôme : Taille ARC apparemment plafonnée ou plus petite que prévu.

Cause racine : zfs_arc_max défini intentionnellement ou par défaut distro ; pression mémoire ; limites de conteneur ; interactions avec hugepages.

Fix : Inspectez les paramètres ARC et la disponibilité mémoire ; changez les caps délibérément ; ne laissez pas l’OS à court de mémoire.

6) « Les opérations sur petits fichiers sont lentes sur un pool HDD »

Symptôme : Listing de répertoires, untar, opérations git laborieuses.

Cause racine : Seeks de métadonnées sur HDD ; cache de métadonnées insuffisant ; pas de special vdev.

Fix : Assurez une RAM adéquate pour les métadonnées ; envisagez un special vdev pour métadonnées/petits blocs ; vérifiez avec le comportement de hit des métadonnées.

7) « Les performances s’effondrent quand le pool approche du plein »

Symptôme : C’était correct à 60 %, affreux à 90 %.

Cause racine : Overhead d’allocation et fragmentation ; metaslabs contraints ; amplification d’écriture RAIDZ aggravée.

Fix : Ajoutez de la capacité, migrez des données, appliquez quotas/réservations. Ne traitez pas 95 % d’utilisation comme normal.

8) « On a réglé recordsize et maintenant les lectures aléatoires sont pires »

Symptôme : La latence augmente après changement des settings dataset.

Cause racine : recordsize inadapté à la charge ; changement du pattern I/O et du comportement du cache ; mismatch avec la taille de bloc applicative.

Fix : Utilisez le recordsize approprié par dataset ; testez avec une charge représentative ; ne le changez pas globalement en panique.

Listes de vérification / plan pas à pas

Plan A : Vous achetez du matériel et voulez dimensionner la RAM sans religion

1. Écrivez la charge. VMs ? NFS home dirs ? Objet store ? Base de données ? Mixte ?
2. Choisissez deux métriques qui comptent. Exemple : p95 latence lecture et p95 latence écriture sync.
3. Décidez l’hypothèse du hot set. « On pense que 200 Go sont relus pendant les heures ouvrées. » Mettez un chiffre.
4. Choisissez une baseline RAM conservatrice. Laissez de la place pour l’OS/applis ; planifiez de capper l’ARC.
5. Choisissez une topologie de pool pour les IOPS en premier. Miroirs et plus de vdevs battent les RAIDZ larges pour les charges aléatoires.
6. Décidez si l’accélération des métadonnées est nécessaire. Si oui, envisagez des special vdevs (avec redondance) plutôt que de la RAM infinie.
7. Prévoyez l’observabilité. Stats ARC, latence, swap, CPU et métriques par vdev dès le jour 1.
8. Faites un test de charge ressemblant à la production. Si vous ne pouvez pas, vous devinez—admettez-le et ajoutez une marge de sécurité.

Plan B : La production est lente et vous avez besoin d’un fix à risque minimal

1. Vérifiez le swap et le reclaim. Si swap, cappez l’ARC et stabilisez.
2. Vérifiez le remplissage du pool. Si dangereusement plein, arrêtez et corrigez la capacité. Le reste est cosmétique.
3. Vérifiez la latence et le comportement sync. Identifiez si ce sont les lectures ou les écritures le problème.
4. Identifiez la pollution du cache. Sauvegardes et scans sont des coupables fréquents.
5. Réglez les propriétés par dataset ensuite seulement. Faites-le dataset par dataset, avec notes de rollback.
6. Réévaluez avec les mêmes métriques. Si vous n’avez rien mesuré avant, mesurez après et ne prétendez pas avoir prouvé quoi que ce soit.

Plan C : Vous suspectez un sous-dimensionnement RAM pour l’ARC (et voulez des preuves)

1. Confirmez que l’ARC est à/proche du max sous charge normale.
2. Confirmez que le miss% reste élevé pendant la période lente.
3. Confirmez que la charge est lecture-dominante et a de la localité. Lectures aléatoires qui touchent répétitivement le même working set, pas un scan.
4. Confirmez que les disques sont le goulot sur les misses. Si les SSD sont déjà assez rapides, le bénéfice ARC peut être marginal.
5. Ajoutez de la RAM ou réallouez de la mémoire et retestez. L’amélioration doit se voir sur la p95 latence, pas seulement « on a l’impression que c’est mieux ».

FAQ

1) Combien de RAM ai-je besoin pour ZFS ?

Assez pour exécuter votre charge sans swap, plus assez d’ARC pour réduire significativement vos lectures coûteuses. Commencez avec une baseline sensée (16–64 Go selon le rôle),
mesurez les misses ARC et la latence, puis augmentez la RAM uniquement si et quand cela réduit votre goulot.

2) La règle « 1 Go RAM par To » est-elle utile parfois ?

Comme avertissement que « de grands pools avec des charges métadonnées lourdes sur disques lents ont besoin de mémoire », oui. Comme spécification d’achat, non.
Elle ignore les IOPS, la charge, le tuning dataset, et la réalité des données froides.

3) Plus d’ARC améliore-t-il toujours les performances ?

Non. Si vous êtes limité par la latence d’écriture, le CPU, la topologie, ou la pollution du cache, plus d’ARC peut ne rien faire ou empirer les choses en augmentant la pression mémoire.

4) Dois-je limiter l’ARC ?

Sur des serveurs à usage mixte (hyperviseurs, hôtes de conteneurs, machines exécutant des DB), oui—limitez-le délibérément.
Sur des appliances de stockage dédiées, vous pouvez le laisser croître, mais validez le comportement sous pression et après reboot.

5) Quel taux de hit ARC est « bon » ?

« Bon » c’est quand la latence applicative atteint l’objectif. Le taux de hit est contextuel. Une charge de streaming peut avoir un faible hit% et être correcte.
Une charge VM avec faible hit% et forte latence de lecture sera pénible.

6) Quand L2ARC a-t-il du sens ?

Quand votre working set est plus grand que la RAM mais a encore de la localité, et que vos disques sont assez lents pour que les hits SSD comptent.
Aussi quand vous avez assez de RAM pour l’alimenter. L2ARC n’est pas un pansement pour une mauvaise topologie de pool.

7) ZFS est-il « gourmand en mémoire » comparé à d’autres systèmes de fichiers ?

ZFS utilisera volontiers la RAM disponible pour l’ARC parce que c’est utile. Cela peut paraître « gourmand » sur les tableaux de bord.
La question n’est pas « l’ARC est-il gros », mais « le système est-il stable et la latence s’améliore-t-elle ».

8) La compression change-t-elle les besoins en RAM ?

Souvent, oui—dans le bon sens. La compression peut augmenter la capacité effective de l’ARC parce que plus de données logiques tiennent par octet mis en cache, et elle réduit l’I/O disque.
Mais si le CPU devient contraint, vous avez juste déplacé le goulot.

9) Qu’en est-il de la déduplication ?

Ne l’utilisez que si vous pouvez prouver les économies et si vous comprenez les implications mémoire et performance pour votre version et votre charge.
Activer la dédup sans plan, c’est vous porter volontaire pour un incident.

10) Pourquoi les performances changent-elles après un reboot ?

L’ARC démarre froid. Si vos performances dépendent d’un cache chaud, vous verrez une période lente après reboot.
C’est un comportement normal de cache. Résolvez-le avec assez de RAM, une conception consciente de la charge, et en évitant les suppositions « dépendantes du cache » pour les chemins critiques.

Prochaines étapes réalisables cette semaine

Si vous voulez une décision de dimensionnement ARC défendable—une qui ne se fera pas ridiculiser en revue—faites ceci dans l’ordre :

1. Baselinez le système : collectez free -h, vmstat, stats ARC, et zpool iostat pendant une période lente.
2. Séparez le problème : décidez si vous êtes limité en lecture, écriture, ou latence sync. Ne devinez pas.
3. Retirez l’automutilation évidente : corrigez le remplissage du pool, arrêtez le swap, et empêchez les backups d’écraser votre cache.
4. Réglez par dataset : alignez recordsize, primarycache, et atime avec la charge.
5. Ensuite seulement, achetez de la RAM : si les misses restent élevés sous une localité stable et que les disques sont le goulot, ajoutez de la RAM et vérifiez l’amélioration avec les mêmes métriques.

Si quelqu’un insiste pour « RAM par To », posez-lui une question : « Quelle charge et quel objectif de latence ? » S’il ne peut pas répondre, il ne dimensionne pas. Il récite.