L2ARC ZFS sur NVMe : quand ça vaut le coup (et quand l’ARC suffit)

décembre 9, 2025 • février 3, 2026 • Lecture : 28 min • Views: 12

Cet article vous a aidé ?

ZFS a la réputation d’être « magique », prononcée généralement sur le même ton que pour une machine à expresso. Les hits ARC sont rapides, les sommes de contrôle rassurantes, et les snapshots vous donnent l’air compétent sous pression. Puis la charge augmente, la RAM cesse d’être bon marché (ou simplement disponible), et quelqu’un suggère : « Ajoutez un L2ARC sur NVMe. »

Parfois c’est exactement la bonne décision. D’autres fois, c’est une manière plus coûteuse d’obtenir la même performance qu’en donnant simplement plus de mémoire à l’ARC, en corrigeant le recordsize, ou en empêchant votre application de lire le même bloc de 4 Ko dans un motif de 1 Mo. L2ARC n’est pas un bouton universel « rendre ZFS plus rapide » ; c’est un levier très spécifique avec des bords tranchants.

Ce qu’est L2ARC (et ce que ce n’est pas)

L’ARC (Adaptive Replacement Cache) est le cache principal de ZFS, situé en RAM. Il met en cache les données (et les métadonnées) et est extrêmement efficace parce que la latence de la RAM est minime et que l’ARC est étroitement intégré au pipeline I/O de ZFS.

L2ARC est un cache secondaire qui vit généralement sur un périphérique rapide comme le NVMe. Il stocke des copies des blocs de données qui étaient auparavant dans l’ARC et qui sont jugés suffisamment utiles pour être conservés lorsque l’ARC a besoin d’espace. L2ARC ne remplace pas l’ARC ; il l’étend.

Ce que L2ARC n’est pas :

Pas un cache d’écriture. Les écritures ZFS sont gérées par des groupes de transactions, le ZIL, et (si présent) un périphérique SLOG. L2ARC aide les lectures.
Pas une garantie. C’est un cache avec éviction et comportement de réchauffement, et il peut être froid après un redémarrage.
Pas gratuit. Il consomme du CPU et de la mémoire pour les en-têtes/l’indexation, génère des lectures/écritures supplémentaires sur le périphérique cache, et peut voler de la bande passante à votre pool s’il est mal dimensionné ou mal utilisé.

Deux phrases d’humour, comme promis, puis restons professionnels : ajouter L2ARC pour corriger la latence de lectures aléatoires, c’est comme ajouter un deuxième frigo pour mieux cuisiner — parfois ça aide, mais seulement si vous avez réellement de la nourriture à stocker. Aussi, « cache » est le seul mot en informatique qui signifie à la fois « plus rapide » et « plus compliqué ».

Faits intéressants et contexte historique

L’ARC n’est pas juste LRU. Il combine récence et fréquence via un algorithme adaptatif, ce qui compte quand les charges mélangent scans et jeux chauds.
L2ARC est arrivé tôt dans la vie de ZFS. Il a été conçu à une époque où les SSD étaient plus petits et l’endurance était une préoccupation majeure, d’où l’importance de son comportement d’écriture et de ses réglages.
Les premières versions de L2ARC ne persistaient pas après un reboot. Beaucoup d’installations ont appris à leurs dépens qu’un redémarrage pouvait « effacer » les performances jusqu’à ce que le cache se réchauffe à nouveau.
OpenZFS moderne peut persister L2ARC. Le L2ARC persistant réduit le effet « lent le lundi matin après un patch » — si vous le configurez et le supportez correctement.
Le cache n’est pas que des données. Les métadonnées ZFS (données dnode, blocs indirects) donnent souvent des gains de performance disproportionnés lorsqu’elles sont en cache, surtout pour de grands arbres de répertoires et des images VM.
Le NVMe a changé l’économie. Il a rendu « assez rapide pour agir comme cache » beaucoup moins cher et plus compact, mais a aussi facilité la saturation des lanes PCIe ou la déclenchement du throttling thermique sous écritures soutenues.
Les écritures L2ARC peuvent être implacables. L2ARC se peuple en écrivant des données depuis le flux d’éviction de l’ARC ; sous pression, il peut créer une usure et une utilisation de bande passante steady sur le périphérique.
La compression change les maths du cache. ARC/L2ARC stockent des blocs compressés (lorsque la compression est activée), augmentant effectivement la « capacité » du cache d’une manière que beaucoup de feuilles de calcul de dimensionnement oublient.

Pourquoi l’ARC gagne par défaut

L’ARC est l’endroit où ZFS souhaite que vos lectures chaudes atterrissent. Il est plus rapide que n’importe quel NVMe, et il permet à ZFS de prendre des décisions de cache avec un minimum de surcharge. Il met aussi en cache les métadonnées agressivement, ce qui est souvent plus important que mettre en cache les données en vrac.

En production, j’ai vu plus de gains de performance en :

Ajoutant de la RAM (ou empêchant qu’elle soit volée par ballooning / autres services)
Corrigeant le recordsize (et volblocksize pour les zvols)
Activant la compression (surtout lz4) pour réduire les I/O
Corrigeant les réglages sync et en utilisant un SLOG correctement (pour les problèmes de latence d’écriture)
Séparant les métadonnées sur un vdev spécial lorsque la charge est riche en métadonnées

L2ARC doit être envisagé lorsque vous avez un jeu de données chaud connu trop grand pour la RAM mais encore assez petit pour tenir dans un cache NVMe réaliste, et lorsque l’écart de latence entre le NVMe et votre pool est significatif.

Quand L2ARC sur NVMe en vaut la peine

1) Vous avez un « jeu chaud » plus grand que la RAM mais plus petit que le NVMe

Exemple classique : un hôte de virtualisation avec des dizaines de VM où les blocs « chauds » de chaque VM ne sont pas énormes, mais l’ensemble chaud total fait des dizaines à centaines de Go. L’ARC ne peut pas tout contenir, et le pool est sur HDD ou SSD saturés. L2ARC sur un bon NVMe peut augmenter les IOPS de lecture et réduire la latence en queue.

2) Votre pool est lent en lectures aléatoires

Si votre pool principal est composé de miroirs HDD/RAIDZ, les lectures aléatoires vous coûtent des mouvements mécaniques. L2ARC peut transformer la « pénalité de lecture aléatoire » en « latence de lecture NVMe », ce qui améliore vraiment l’expérience de démarrage de VM, d’installation de paquets et de builds CI dépendantes.

3) Vous avez du CPU disponible et vous êtes sensible à la latence

L2ARC n’est pas gratuit : il ajoute des cycles CPU pour la somme de contrôle, la gestion de la compression et la gestion du cache. Si l’hôte a du CPU libre et que la charge punit la latence de queue (p95/p99), L2ARC peut être un bon compromis.

4) Vous pouvez tolérer le comportement de réchauffement ou vous avez L2ARC persistant

Si votre parc redémarre régulièrement (mises à jour noyau, firmware, coupures), un L2ARC non persistant peut rendre les performances incohérentes. Le L2ARC persistant peut aider, mais il ajoute des considérations opérationnelles : fiabilité du périphérique, temps d’importation et validation.

5) Votre application effectue des lectures répétées, pas seulement du streaming

L2ARC adore la réutilisation. Si votre charge est « lecture unique » (sauvegardes, scans séquentiels volumineux), L2ARC peut devenir un générateur d’écritures sophistiqué qui met en cache surtout les données d’hier.

Quand l’ARC suffit (et L2ARC est une distraction)

1) Votre pool est déjà NVMe/SSD et n’est pas le goulot d’étranglement

Si votre pool est sur SSD rapide et que votre application est limitée par le CPU ou par des verrous, L2ARC ne résoudra rien. Vous ajouterez juste une couche supplémentaire à gérer.

2) Vous n’avez pas de marge mémoire

L2ARC consomme de la mémoire pour ses structures d’en-têtes/index. Si vous êtes déjà court en RAM, ajouter L2ARC peut aggraver la situation en réduisant l’ARC effectif et en poussant le système en pression de recollection. Le résultat peut être une latence pire et plus d’I/O disque.

3) Votre problème concerne les écritures, pas les lectures

Si le problème est la latence des écritures synchrones (bases de données, NFS en sync, tempêtes de flush VM), vous êtes en territoire SLOG. Si le problème est le débit d’écriture en masse, regardez l’agencement des vdevs, le recordsize et la bande passante des périphériques. L2ARC n’aidera pas beaucoup au-delà de rendre vos tableaux de bord plus occupés.

4) Votre jeu de travail est « trop grand pour être mis en cache » en pratique

Si l’ensemble actif fait plusieurs téraoctets et que votre L2ARC proposé est de 400 Go, il est possible qu’il n’améliore pas significativement le taux de hits. L2ARC aide quand il peut garder une fraction significative de l’ensemble relu.

Choix du périphérique NVMe : détails ennuyeux mais importants

Pour L2ARC, vous voulez un périphérique capable de soutenir des lectures aléatoires mixtes et un flux d’écritures constant sans s’effondrer quand son cache SLC est épuisé. Le NVMe grand public peut paraître brillant dans les benchs puis se throttler ou s’effondrer sous écritures soutenues — exactement le schéma que L2ARC peut générer quand l’ARC est en churn.

Notes pratiques de sélection :

L’endurance (TBW/DWPD) compte. L2ARC peut écrire en continu. Si vous l’ajoutez pour « économiser », ne choisissez pas un périphérique qui devient consommable rapidement.
La protection contre la perte de puissance est appréciable. L2ARC n’est pas un journal d’écriture, mais une coupure brutale peut toujours provoquer des surprises désagréables dans le comportement du périphérique, et le L2ARC persistant profite d’une intégrité média prévisible.
Les thermiques sont réels. Les périphériques NVMe peuvent se throttler sous écritures soutenues. Si votre serveur a un flux d’air limité, L2ARC peut devenir un chauffant accidentel avec pénalité de performance.
Ne partagez pas le périphérique avec d’autres I/O lourdes. Un NVMe « cache » qui héberge aussi logs, conteneurs et base de données vous apprendra la contention.

Dimensionner L2ARC : capacité, marge et attentes

Dimensionner L2ARC, ce n’est pas « plus grand c’est mieux » mais plutôt « plus grand c’est plus d’en-têtes et plus de temps de warm-up ». L2ARC a besoin de RAM pour sa gestion interne. Si vous ajoutez un énorme L2ARC à un système à mémoire modeste, vous pouvez affamer l’ARC et perdre.

Règles empiriques qui tiennent en production :

Commencez petit. Un L2ARC modeste (de dizaines à quelques centaines de Go) peut produire la majeure partie du bénéfice sans surcharge excessive.
Préférez plus de RAM plutôt que plus de L2ARC. Si vous pouvez ajouter de la RAM, faites-le d’abord. Les hits ARC sont moins coûteux et plus prévisibles que les hits L2ARC.
Mesurez le taux de hits et la latence, pas les impressions. L2ARC peut améliorer l’aspect des graphes tandis que la latence p99 reste mauvaise parce que vous êtes bottleneck ailleurs.
Attendez-vous à un warm-up. Un cache froid signifie retour à la performance du pool jusqu’à ce que la charge rejoue suffisamment de lectures.

Réglages qui font vraiment la différence

La plupart des réglages L2ARC concernent le contrôle du churn et la décision de ce qui est admis. Les paramètres par défaut sont souvent conservateurs, mais « tout monter » peut nuire — surtout sur des systèmes occupés.

Concepts clés :

Débit d’alimentation : À quelle vitesse L2ARC est peuplé par les buffers d’éviction de l’ARC. Un débit plus élevé réchauffe plus vite mais augmente la charge d’écriture.
Politique d’admission : Cacher seulement certains types de données (métadonnées vs données), et prioriser ou non les blocs fréquemment utilisés.
Interaction avec le préfetch : Mettre en cache des données préfetchées peut être coûteux quand les charges streament.
L2ARC persistant : Utile pour les environnements à redémarrages fréquents, mais modifie le comportement d’import et les attentes opérationnelles.

Trois mini-récits du monde de l’entreprise

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

C’était un cluster de virtualisation de taille moyenne. Le stockage était un pool ZFS sur miroirs HDD (solide, si pas glamour). Les plaintes de performance montaient : tempêtes de démarrages de VM le matin, fenêtres de patch qui traînaient, et des tickets « le stockage est lent » sans métriques.

Un ingénieur bien intentionné a proposé L2ARC sur un NVMe. L’hypothèse : « cache NVMe = lectures plus rapides = problème résolu. » Ils ont ajouté un gros périphérique cache, et le premier jour c’était mieux — quelques démarrages plus rapides, la hotline s’est tue. Puis la maintenance hebdomadaire a redémarré les hôtes.

Après le reboot, les performances ont chuté. Pas seulement au niveau de base — pire. L’hôte a thrashé : l’ARC a rétréci parce que le système manquait de mémoire, les en-têtes L2ARC ont consommé plus de RAM que prévu, et le cache était froid. La tempête de démarrages a frappé le pool lent, la file d’attente de l’hyperviseur a explosé. La latence a gonflé et quelques VM ont eu des timeouts I/O. Le rapport d’incident commençait par « Nous avons récemment fait un changement… » et a fini avec un nouveau processus d’approbation.

La correction n’a pas été héroïque. Ils ont retiré le L2ARC surdimensionné, ajouté de la RAM pour restaurer la marge ARC, et activé le L2ARC persistant seulement après avoir confirmé le support noyau/module et mesuré le comportement d’import. La leçon : L2ARC n’est pas un accélérateur à « configurer et oublier » ; il a une relation avec la RAM, et le comportement après reboot compte si vos charges ont des tempêtes prévisibles.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une plateforme d’ingénierie des données avait un store objet sur ZFS pour des artefacts intermédiaires. Les lectures étaient « assez aléatoires », et quelqu’un a remarqué que le taux de hits ARC n’était pas génial. L’équipe a ajouté un NVMe grand public haut de gamme en L2ARC et a décidé de « le faire vraiment fonctionner » en augmentant le débit d’alimentation L2ARC et en mettant en cache plus agressivement.

En quelques jours, le NVMe a commencé à signaler des erreurs média. SMART affichait des signes inquiétants. Ce qui s’est passé n’était pas mystérieux : la charge avait un churn énorme, le périphérique était écrit en continu, et le comportement d’écriture soutenue du disque sous chaleur n’était pas ce que la fiche technique laissait entendre. La machine ne tombait pas en panne parce que NVMe est mauvais ; elle tombait en panne parce que la charge avait transformé le « cache » en tapis roulant d’écritures.

Même avant les erreurs, les gains étaient inconsistants. Le débit max s’améliorait parfois, mais les latences en queue empirent pendant les phases d’ingestion lourde parce que le système passait du temps à alimenter le L2ARC tout en essayant de servir des lectures. L’optimisation n’a pas seulement échoué — elle a créé un nouveau goulot et un nouveau domaine de panne.

Ils ont remplacé le périphérique par un NVMe orienté endurance, réduit le débit d’alimentation, et changé l’admission pour éviter de mettre en cache des flux lourds en préfetch. Le changement le plus important : ils ont reconnu que la charge était fondamentalement de streaming et ont modifié le pipeline pour réduire les relectures. L2ARC est devenu un assistant modeste, pas la stratégie principale.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une application financière opérait sur ZFS, avec des fenêtres de maintenance strictes et une tolérance minimale aux surprises. L’équipe souhaitait L2ARC pour un grand jeu de données de référence consulté en boucle pendant les heures ouvrées. Ils ont fait l’impopulaire chose : ils ont procédé par étapes.

Puis ils ont mesuré : taille ARC, taux de hits ARC, misses de cache, distribution de latence de lecture, et I/O pool. Ils ont établi une ligne de base pendant l’heure la plus chargée puis pendant les périodes calmes. Ensuite ils ont ajouté un petit L2ARC sur un NVMe serveur-grade avec bonne endurance. Aucun réglage au départ ; juste observer.

Ils ont aussi mis en place des garde-fous opérationnels : alertes sur la température NVMe et les erreurs média, tendances sur le taux de hits L2ARC, et une procédure de rollback incluant le retrait propre du périphérique cache. Ils ont testé le comportement au reboot et confirmé que le temps d’import du L2ARC persistant était acceptable.

Quand un incident ultérieur est survenu — un déploiement applicatif qui a involontairement doublé l’amplification de lecture — le stockage n’est pas devenu le bouc émissaire. Les métriques rendaient évident : le taux de misses ARC a grimpé, L2ARC aidait mais était saturé, et le pool voyait encore trop de lectures aléatoires. Parce qu’ils avaient une instrumentation propre, ils ont corrigé l’application et gardé le stockage stable. Les pratiques ennuyeuses ont sauvé la mise : lignes de base, changements par étapes, et alertes déclenchées avant les utilisateurs.

Tâches pratiques (commandes + interprétation)

Les commandes ci-dessous supposent un système Linux avec OpenZFS installé. Ajustez les chemins pour votre distribution. L’intention ici est opérationnelle : « lancez ceci, lisez cela, décidez ensuite. »

Task 1: Identify pool layout and current cache devices

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
        cache
          nvme0n1                   ONLINE       0     0     0

errors: No known data errors

Interprétation : Confirme si un L2ARC existe (« cache ») et affiche les erreurs éventuelles. Si vous voyez read/write/cksum errors sur le périphérique cache, traitez-le comme un composant en panne — pas « juste un cache ».

Task 2: Confirm dataset properties that influence caching

cr0x@server:~$ sudo zfs get -o name,property,value -s local,received compression,recordsize,primarycache,secondarycache tank/datasets/vmstore
NAME                  PROPERTY        VALUE
tank/datasets/vmstore  compression     lz4
tank/datasets/vmstore  primarycache    all
tank/datasets/vmstore  secondarycache  all
tank/datasets/vmstore  recordsize      128K

Interprétation : Si secondarycache=none, L2ARC ne servira à rien. Si primarycache=metadata, vous réservez volontairement l’ARC aux métadonnées — valide pour certaines charges, mais cela change les attentes.

Task 3: Check ARC size, target, and pressure

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|memory_throttle_count)'
size                            4    34359738368
c_min                           4    8589934592
c_max                           4    68719476736
memory_throttle_count           4    0

Interprétation : La taille ARC est l’utilisation actuelle ; c_max est le plafond. Un memory_throttle_count non nul suggère que l’ARC est forcé de décroître à cause de la pression mémoire — souvent un signe que L2ARC pourrait nuire si vous ajoutez plus de surcharge.

Task 4: Measure ARC hit ratio vs misses (quick sanity)

cr0x@server:~$ awk '
/^hits /{h=$3}
/^misses /{m=$3}
END{
  total=h+m;
  if(total>0) printf("ARC hit%%: %.2f\n", (h/total)*100);
}' /proc/spl/kstat/zfs/arcstats
ARC hit%: 92.14

Interprétation : Un ARC hit% élevé signifie souvent que l’ARC fait déjà bien son travail. Si la performance est mauvaise malgré tout, votre goulot n’est peut-être pas le cache de lecture.

Task 5: Check L2ARC effectiveness (hit ratio and size)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(l2_size|l2_hits|l2_misses|l2_read_bytes|l2_write_bytes)'
l2_hits                         4    1843200
l2_misses                       4    921600
l2_size                         4    214748364800
l2_read_bytes                   4    9876543210
l2_write_bytes                  4    45678901234

Interprétation : Si l2_hits est faible et l2_write_bytes énorme, vous pourriez écrire un cache rarement lu. C’est une taxe sur l’endurance et la bande passante sans réel bénéfice.

Task 6: Watch real-time ARC/L2ARC behavior (one-liner)

cr0x@server:~$ sudo arcstat 1
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  l2hits  l2miss  l2miss%  l2read  l2write
12:00:01   320    22      6     3   14    19   86     0    0   32G   64G     120      40       25     60M    280M

Interprétation : Cherchez si les misses se corrèlent avec la douleur de latence, et si L2ARC réduit significativement les misses. Si L2ARC écrit beaucoup pendant que vous êtes lié par la latence, envisagez de réduire le débit d’alimentation ou d’ajuster l’admission.

Task 7: Confirm device health and wear (NVMe SMART)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1
Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 48 C
available_spare                     : 100%
percentage_used                     : 7%
data_units_read                     : 12,345,678
data_units_written                  : 98,765,432
media_errors                        : 0
num_err_log_entries                 : 0

Interprétation : Une percentage_used qui monte rapidement après l’ajout de L2ARC est un indice que vous transformez le NVMe en charge d’écriture. La température proche des plages de throttling est aussi un signal d’alerte.

Task 8: Verify pool-level read latency and I/O mix

cr0x@server:~$ sudo zpool iostat -v tank 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  ----- -----  ----- -----
tank        3.20T  6.80T    850   220   85.0M  12.0M
  mirror-0  3.20T  6.80T    850   220   85.0M  12.0M
    sda         -      -    430   110   42.5M   6.0M
    sdb         -      -    420   110   42.5M   6.0M
cache                          -      -    200     0   20.0M   0.0M
  nvme0n1                      -      -    200     0   20.0M   0.0M

Interprétation : Confirme si les lectures sont réellement servies depuis le périphérique cache. Montre aussi si le pool est saturé en opérations de lecture.

Task 9: Add an L2ARC device safely

cr0x@server:~$ sudo zpool add tank cache /dev/nvme0n1

Interprétation : Ceci attache l’intégralité du NVMe comme cache. Dans beaucoup de configurations de production vous voudrez des partitions et des noms stables par id ; ceci reste l’action centrale.

Task 10: Remove an L2ARC device safely

cr0x@server:~$ sudo zpool remove tank nvme0n1

Interprétation : Les périphériques cache sont amovibles. Si vous dépannez ou avez choisi le mauvais disque, le retrait est simple — ne débranchez pas le périphérique brutalement en espérant le meilleur.

Task 11: Set dataset-level policies for what goes into L2ARC

cr0x@server:~$ sudo zfs set secondarycache=metadata tank/datasets/vmstore
cr0x@server:~$ sudo zfs get secondarycache tank/datasets/vmstore
NAME                  PROPERTY        VALUE     SOURCE
tank/datasets/vmstore  secondarycache  metadata  local

Interprétation : Ceci peut être un contrôle puissant quand les données sont volumineuses et en streaming mais que les métadonnées sont chaudes. Si votre L2ARC était rempli par de grandes lectures séquentielles, cela le calme souvent.

Task 12: Check and adjust ARC limits (carefully)

cr0x@server:~$ sudo bash -c 'echo 68719476736 > /sys/module/zfs/parameters/zfs_arc_max'
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_max
68719476736

Interprétation : Si votre système a de la RAM mais que l’ARC est artificiellement limité, augmenter zfs_arc_max peut surpasser n’importe quel L2ARC que vous pourriez acheter. Ne le montez pas tellement que le noyau et les applications manquent de mémoire.

Task 13: Check prefetch behavior impacts (high-level)

cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_prefetch_disable
0

Interprétation : Le prefetch est utile pour les lectures séquentielles, mais il peut polluer les caches selon certains motifs. Désactiver globalement le prefetch est rarement la bonne première action ; considérez plutôt des politiques de dataset ou le tuning d’admission pour L2ARC si votre implémentation le supporte.

Task 14: Confirm compression and logical vs physical reads

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

Interprétation : La compression augmente la capacité effective du cache. Un ratio de 1.78x signifie que votre ARC/L2ARC stockent moins de données physiques pour le même ensemble logique.

Méthode de diagnostic rapide

Voici la séquence « c’est lent et tout le monde regarde ». Vous pouvez la lancer en cinq à quinze minutes et sortir avec une hypothèse de travail.

First: Is it reads or writes?

cr0x@server:~$ sudo zpool iostat -v tank 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  ----- -----  ----- -----
tank        3.20T  6.80T    900   120   90.0M   8.0M

Interprétation : Si les écritures dominent et que la latence est le problème, examinez le comportement sync, le SLOG, txg, et les patterns fsync de l’application. L2ARC n’est pas le premier secours.

Second: Are we cache-missing or device-bottlenecked?

cr0x@server:~$ awk '
/^hits /{h=$3}
/^misses /{m=$3}
/^l2_hits /{l2h=$3}
/^l2_misses /{l2m=$3}
END{
  total=h+m;
  l2total=l2h+l2m;
  if(total>0) printf("ARC hit%%: %.2f\n", (h/total)*100);
  if(l2total>0) printf("L2ARC hit%%: %.2f\n", (l2h/l2total)*100);
}' /proc/spl/kstat/zfs/arcstats
ARC hit%: 71.03
L2ARC hit%: 62.50

Interprétation : Un ARC hit% bas et un L2ARC hit% correct suggèrent que L2ARC aide. ARC hit% bas et L2ARC hit% bas suggèrent soit un L2ARC sous-dimensionné, froid, mal admis, ou que la charge a peu de réutilisation.

Third: Is the NVMe cache itself the bottleneck?

cr0x@server:~$ sudo nvme smart-log /dev/nvme0n1 | egrep 'temperature|critical_warning|media_errors|percentage_used'
temperature                         : 72 C
critical_warning                    : 0x00
percentage_used                     : 31%
media_errors                        : 0

Interprétation : Une température élevée peut indiquer du throttling. Une usure rapide suggère que votre politique de cache est trop écriture-intensive pour la classe de périphérique.

Fourth: Is memory pressure sabotaging ARC?

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|memory_throttle_count)'
size                            4    10737418240
c_max                           4    17179869184
memory_throttle_count           4    921

Interprétation : Si memory_throttle_count augmente, l’ARC est compressé. Ajouter un L2ARC dans cet état aggrave souvent la situation. Envisagez d’ajouter de la RAM, réduire le plafond ARC seulement si nécessaire, et corriger le véritable consommateur de mémoire.

Fifth: Confirm you’re not chasing the wrong problem

cr0x@server:~$ sudo iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.10    0.00    6.40    1.20    0.00   70.30

Device            r/s     w/s   rkB/s   wkB/s  await  %util
sda             55.0    12.0  6400.0  1100.0  18.2   92.0
nvme0n1        210.0    95.0 24000.0 33000.0   1.9   78.0

Interprétation : Si vos disques sont saturés et que la latence est élevée, le cache peut aider — mais si le CPU est saturé, ou l’appli bloquée sur autre chose, vous optimisez la mauvaise couche.

Erreurs courantes : symptômes et corrections

Mistake 1: Using L2ARC to fix sync write latency

Symptôme : Les utilisateurs se plaignent de commits/transactions lents ; les métriques montrent des pics de latence d’écriture ; les métriques de lecture ne sont pas le problème.

Correction : Évaluez la charge sync : considérez un vrai périphérique SLOG, vérifiez les réglages sync (et si vous êtes autorisé à les changer), et profilez les patterns fsync. L2ARC n’est pas pertinent ici.

Mistake 2: Oversizing L2ARC on a RAM-poor host

Symptôme : Après avoir ajouté le cache, la taille ARC rétrécit, memory_throttle_count augmente, et la latence globale empire — surtout au démarrage.

Correction : Réduisez ou retirez le L2ARC, ajoutez de la RAM, et confirmez que les limites ARC sont raisonnables. Si vous conservez L2ARC, gardez-le modeste et mesurez.

Mistake 3: Caching streaming reads and filling L2ARC with junk

Symptôme : Les octets écrits sur L2ARC augmentent rapidement, le pourcentage de hits L2ARC reste faible, l’usure NVMe augmente, et les gains de performance sont minimes.

Correction : Mettez secondarycache=metadata pour les datasets streaming, ou limitez autrement ce qui est admis ; évitez de mettre en cache les flux à préfetch lourds si possible.

Mistake 4: Sharing the L2ARC NVMe with other services

Symptôme : Pics de latence aléatoires qui se corrèlent avec des pulls d’images conteneurs, des rafales de logs, ou des compactions de base de données sur le même NVMe.

Correction : Dédiez le périphérique (ou au moins isolez-le avec des partitions et des contrôles I/O). Un périphérique cache ne doit pas être un disque scratch multi-usage en production.

Mistake 5: Expecting immediate improvement after adding L2ARC

Symptôme : « Nous avons ajouté le cache et rien n’a changé. » Puis, quelques jours plus tard, c’est mieux — ou pire — selon le churn de la charge.

Correction : Planifiez le warm-up. Si l’environnement redémarre souvent et que la cohérence est importante, évaluez le L2ARC persistant et mesurez explicitement la performance post-reboot.

Mistake 6: Ignoring NVMe thermals and endurance

Symptôme : Throttling, chutes soudaines de performance, sauts d’usure SMART, ou erreurs média après un déploiement « réussi ».

Correction : Utilisez des NVMe orientés endurance, assurez le flux d’air, surveillez température et usure, et ajustez le débit/admission L2ARC pour réduire l’intensité d’écritures.

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

Step-by-step: deciding whether you need L2ARC

Confirmez que le problème est la latence de lecture/IOPS. Utilisez zpool iostat et des outils système ; ne devinez pas.
Mesurez l’efficacité de l’ARC. Si ARC hit% est déjà élevé, concentrez-vous ailleurs.
Estimez la taille du jeu de travail. Même approximatif : « quelle quantité de données est relue pendant l’heure de pointe ? » Si c’est bien au-delà du NVMe abordable, L2ARC ne sera pas miraculeux.
Vérifiez la marge de RAM. Si l’hôte est juste en mémoire, planifiez la RAM d’abord.
Considérez la politique de cache des datasets. Si la plupart des lectures sont en streaming, L2ARC peut nuire à moins d’être restreint aux métadonnées ou à des sous-ensembles chauds.
Évaluez les alternatives. Réglages recordsize/volblocksize, compression, vdev spécial pour métadonnées, ou simplement des vdevs plus rapides peuvent offrir un meilleur ROI.

Step-by-step: deploying L2ARC safely

Choisissez le NVMe adapté. Endurance et performance soutenue valent mieux que des benchs tape-à-l’œil.
Capturez des métriques de base. Enregistrez ARC/L2ARC stats, iostat du pool, distributions de latence pendant la pointe.
Ajoutez d’abord un périphérique cache modeste. Ne commencez pas par « aussi grand que possible ».
Laissez les valeurs par défaut au début. Observez au moins un cycle de charge (journée/semaines).
Validez le comportement au reboot. Si la performance après reboot est inacceptable, évaluez le L2ARC persistant ou acceptez le temps de warm-up.
Définissez la politique secondarycache au niveau dataset. Surtout pour les datasets connus pour faire du streaming.
Surveillez la santé du NVMe. Température, usure, erreurs média ; alertez avant que ça devienne une panne surprise.
Documentez le rollback. Pratiquez zpool remove et confirmez le comportement attendu lors du retrait propre.

FAQ

1) Est-ce que L2ARC accélère les écritures ?

Non. L2ARC sert les lectures. Si votre problème d’écriture est la latence sync, cherchez à régler le SLOG et le choix des périphériques. Si c’est le débit, regardez l’agencement des vdevs et la bande passante.

2) Est-il mieux d’acheter plus de RAM ou d’ajouter du NVMe pour L2ARC ?

Plus de RAM gagne généralement. Les hits ARC sont plus rapides et plus simples que les hits L2ARC, et la RAM n’introduit pas de contention sur un périphérique ni de souci d’endurance. L2ARC sert quand la RAM ne peut pas raisonnablement contenir le jeu de travail.

3) Quelle taille devrait faire le L2ARC ?

Assez grand pour contenir une portion significative du jeu de travail relu, mais assez petit pour éviter une surcharge mémoire excessive et un long warm-up. Commencez modeste, mesurez, et augmentez seulement si les taux de hits et la latence s’améliorent.

4) Pourquoi les performances ont-elles empiré après l’ajout de L2ARC ?

Raisons courantes : pression mémoire réduisant l’ARC effectif, L2ARC rempli par des lectures streaming/prefetch, contention sur le périphérique cache, ou NVMe incapable de soutenir le pattern d’écriture et qui throttling.

5) Puis-je utiliser un NVMe grand public pour L2ARC ?

Vous pouvez, mais vous prenez des risques : limites d’endurance, throttling thermique, et comportement d’écriture soutenue imprévisible. En production, les périphériques endurance-rated coûtent souvent moins que l’incident que vous finirez par écrire.

6) Dois-je mettre uniquement les métadonnées en cache ou tout ?

Le cache métadonnées seulement est souvent le meilleur « défaut sûr » pour les charges mixtes ou streaming-heavy. Mettre tout en cache peut aider les jeux de lecture VM et base de données, mais peut aussi augmenter le churn et l’usure si votre pattern d’accès n’a pas beaucoup de réutilisation.

7) Le L2ARC persistant élimine le warm-up ?

Il réduit le warm-up après reboot, mais ne l’élimine pas dans tous les cas. Vous devez toujours valider le comportement d’import, la fiabilité du périphérique, et que le cache persisté correspond à la réalité des données après des changements.

8) Comment savoir si L2ARC est réellement utilisé ?

Regardez l2_hits, l2_read_bytes, et des outils temps réel comme arcstat. Vérifiez aussi que les lectures du pool diminuent quand les hits L2ARC augmentent. Si L2ARC écrit beaucoup mais lit peu, il n’est pas utile.

9) L2ARC est-il la même chose qu’un vdev spécial ?

Non. Un vdev spécial stocke certaines classes de données (souvent métadonnées et petits blocs) comme partie intégrante du pool, pas comme cache. Il peut offrir des gains importants et cohérents pour les charges riches en métadonnées, mais change les considérations de redondance et de panne. L2ARC est un cache amovible ; un vdev spécial fait partie du stockage.

Conclusion

L2ARC sur NVMe peut être un outil tranchant légitime : il réduit la latence de lecture et améliore les IOPS de lecture lorsque votre jeu chaud est plus grand que la RAM et que votre pool est plus lent que le NVMe. Mais ce n’est pas un substitut à l’ARC, et ce n’est pas une solution universelle de performance.

En production, le schéma gagnant est constant : mesurer d’abord, ajouter de la RAM quand c’est possible, utiliser L2ARC quand vous avez des lectures répétées et suffisamment de marge, et rester sobre — périphériques dédiés, dimensionnement sensé, et métriques qui vous disent quand le cache aide plutôt que de simplement travailler dur.