ZFS vous donne un super-pouvoir : il transforme la RAM disponible en ARC, un cache de lecture qui peut rendre des disques magnétiques étonnamment performants. Puis quelqu’un remarque un SSD libre, et la conversation commence : zpool add ... cache ....
Parfois L2ARC est clairement bénéfique. D’autres fois c’est un incident au ralenti : rotation du cache, usure du SSD et un budget RAM qui s’évapore silencieusement dans les métadonnées. Voici le guide de production que j’aurais voulu que tout le monde lise avant d’exécuter zpool add ... cache ... un vendredi.
Ce qu’est réellement L2ARC (et ce qu’il n’est pas)
L2ARC est un cache de lecture de second niveau pour ZFS. L’ARC vit en RAM. L2ARC vit sur des périphériques rapides (généralement SSD/NVMe). L’objectif est simple : quand votre « working set » ne tient pas en RAM, garder les blocs « suivants les plus utiles » sur SSD au lieu d’aller les lire sur des disques lents ou un stockage distant.
Mais L2ARC n’est pas une case magique « rendre le stockage plus rapide ». Il est sélectif. Il est opportuniste. Il a un coût. Et il a un tempérament.
Ce qu’est L2ARC
- Un cache de données déjà lues (et, selon les réglages et l’implémentation, parfois du préchargement ou des métadonnées).
- Alimenté par l’ARC : les blocs entrent d’abord dans l’ARC, puis certains sont promus vers le L2ARC.
- Utile surtout quand votre charge effectue des lectures répétées avec un working set plus grand que la RAM mais plus petit que RAM+L2ARC (et suffisamment stable pour chauffer le cache).
Ce qu’il n’est pas
- Ce n’est pas un cache d’écriture (c’est une autre discussion impliquant SLOG/ZIL).
- Ce n’est pas un substitut à la RAM. L’ARC effectue toujours le gros du travail, et L2ARC peut consommer de la RAM pour fonctionner.
- Ce n’est pas une solution de latence garantie. Si votre goulot d’étranglement est le CPU, la fragmentation, les écritures synchrones ou le réseau, L2ARC peut ne rien faire — ou ajouter des problèmes.
Blague en une phrase, comme demandé : L2ARC, c’est comme un abonnement à la salle de sport — on se sent productif en l’acquérant, mais les résultats dépendent de votre assiduité.
Faits et historique : pourquoi L2ARC se comporte ainsi
Un peu de contexte aide. L2ARC ne vient pas d’un monde d’NVMe bon marché et de serveurs avec des tonnes de RAM. Il vient d’une époque où « rapide » signifiait « quelques SSD décents et une prière ». Quelques faits et notes historiques concrets qui ont une portée opérationnelle :
- L’ARC ZFS précède l’économie actuelle du NVMe. L’ARC a été conçu pour utiliser agressivement la RAM parce que la RAM était le stockage le plus rapide que vous pouviez acheter sans réunion d’approvisionnement spéciale.
- L2ARC a été construit comme une extension de l’ARC, pas comme un système de cache séparé. C’est pourquoi les métadonnées et politiques de l’ARC influencent fortement ce qui atterrit dans L2ARC.
- Les premières versions de L2ARC n’étaient pas persistantes après un redémarrage. Un reboot signifiait un cache froid et un long préchauffage. Des travaux ultérieurs d’OpenZFS ont introduit des concepts de L2ARC persistant, mais vous devez valider le comportement sur votre plateforme.
- La durabilité des SSD était autrefois une contrainte de premier ordre. Les écritures d’alimentation du L2ARC peuvent écrire beaucoup de données. Les anciens SSD SLC/SATA pouvaient le supporter ; les TLC grand public bon marché peuvent mourir dramatiquement si on les traite comme une décharge log-structurée.
- L’ARC est adaptatif, mais pas omniscient. Il réagit aux motifs d’accès qu’il a vus ; il ne prédit pas votre prochaine tâche batch, votre pic de connexions du lundi matin, ou votre requête analytique trimestrielle.
- Les métadonnées ZFS peuvent dominer l’I/O sur certaines charges. Si vous parcourez des répertoires, effectuez des sauvegardes ou générez beaucoup d’images VM, les misses de métadonnées peuvent nuire plus que les misses de données.
- Le nom « cache de 2ème niveau » est légèrement trompeur. Ce n’est pas un cache L2 CPU classique inclusif. Vous pouvez avoir des blocs dans l’ARC et le L2ARC, et le système paie un overhead pour les suivre.
- Les alternatives modernes ont changé l’arbre de décision. Des vdevs spéciaux pour métadonnées/petits blocs et des vdevs primaires plus rapides surpassent souvent « ajouter un L2ARC », surtout pour des pools HDD à lectures aléatoires.
Comment fonctionne L2ARC sous le capot
Soyons précis sur le chemin des données, parce que la plupart des incidents L2ARC commencent par un modèle mental vague.
Le chemin de lecture en pratique
Quand une application demande un bloc :
- ZFS vérifie l’ARC (RAM). Si hit : le plus rapide possible, c’est terminé.
- Si l’ARC manque, ZFS vérifie si le bloc est dans le L2ARC (SSD). Si hit : vous payez la latence SSD et un peu de CPU, mais vous évitez le disque rotatif ou le réseau.
- Si L2ARC manque : ZFS lit depuis les vdevs principaux (HDD/SSD), puis le bloc entre dans l’ARC. Plus tard, il peut être écrit dans le L2ARC selon la politique et le taux d’alimentation.
Alimenter le L2ARC n’est pas gratuit
L2ARC ne se remplit pas par magie ; il est écrit sur le disque. Ces écritures proviennent des tampons gérés par l’ARC et sont régies par des paramètres qui limitent l’agressivité avec laquelle ZFS pousse les données dans le L2ARC. Cela signifie :
- Si votre charge change rapidement, L2ARC peut passer son temps à mettre en cache les données d’hier.
- Si votre taux d’alimentation est trop agressif, vous pouvez créer de la pression d’écriture, de l’usure SSD et du CPU supplémentaire, tout en volant de l’espace ARC pour les en-têtes/métadonnées.
Le problème de l’overhead RAM (la partie qu’on oublie)
Pour être utile, L2ARC doit savoir ce qu’il contient. Ce mappage n’est pas entièrement stocké sur le SSD ; ZFS garde des métadonnées en RAM pour décider rapidement si un bloc demandé est en cache et où il se trouve.
Traduction opérationnelle : un grand périphérique L2ARC peut consommer silencieusement une quantité non négligeable de RAM. Si vous manquez déjà de mémoire, ajouter L2ARC peut réduire l’efficacité de l’ARC et augmenter le churn d’éviction — transformant un cache de lecture en taxe de performance.
L’efficacité du cache dépend de la localité d’accès
L2ARC fonctionne mieux lorsqu’il y a de la « réutilisation » : les mêmes blocs sont relus encore et encore sur des minutes/heures/jours. Si votre charge est un scan en un seul passage d’un dataset (lectures en streaming, sauvegardes, grandes analyses linéaires), L2ARC enregistre surtout votre parcours puis l’oublie — après vous avoir facturé les photos souvenirs.
Deuxième blague, comme demandé : en production, L2ARC est innocent jusqu’à preuve du contraire, mais il a d’excellents avocats et un rapport de dépenses suspect.
Quand L2ARC aide (et ce que « aide » veut dire)
L2ARC ne consiste pas à rendre vos lectures les plus rapides encore plus rapides. Il s’agit de transformer vos lectures communes les plus lentes en lectures simplement « plutôt rapides ». Les meilleurs candidats partagent quelques caractéristiques.
Bonnes correspondances
- Charges orientées lecture où le dataset actif est plus grand que la RAM mais assez petit pour tenir dans RAM+L2ARC.
- Jeux de travail stables : tempêtes de démarrage VDI, binaires de serveurs web/app, couches d’images de conteneurs réutilisées, bibliothèques partagées sur serveurs de build, dépôts de paquets.
- Lectures aléatoires sensibles à la latence depuis des pools HDD où chaque miss coûte des millisecondes.
- Environnements où vous ne pouvez pas ajouter assez de RAM (coût, slots, contraintes de plateforme), mais pouvez ajouter un SSD correctement dimensionné et durable.
À quoi ressemble le succès (mesurable)
Dans des systèmes réels, « L2ARC a aidé » signifie typiquement :
- Le ratio de hit ARC reste élevé et le ratio de hit L2ARC est significatif (pas juste du bruit).
- Les IOPS de lecture disque diminuent, ou la latence de lecture disque s’améliore sous la même charge.
- La latence de queue d’application s’améliore (p95/p99), pas seulement le débit moyen.
- L’overhead CPU reste acceptable ; vous n’avez pas échangé la latence disque contre du temps noyau.
Notamment : il peut aider même avec un taux de hit modeste
Si votre pool sous-jacent est basé sur HDD, même un taux de hit L2ARC modeste peut être précieux. Remplacer une lecture aléatoire de 10 ms par une lecture SSD de 100 µs–1 ms change la forme de la file et réduit le blocage en tête de file. Mais vous devez vérifier : si le système est déjà limité ailleurs, vous ne ferez que déplacer la faute.
Quand L2ARC fait du tort : modes de défaillance
L2ARC ne « fait pas mal » parce que les SSD sont lents. Il fait mal parce que vous ajoutez un sous-système avec ses propres coûts en ressources, et ces coûts apparaissent exactement là où ZFS est sensible : mémoire, CPU et ordonnancement I/O.
Mode de défaillance 1 : pression mémoire et effondrement de l’ARC
Le classique : vous ajoutez un grand périphérique L2ARC à une machine qui fonctionnait déjà bien avec l’ARC. Soudain l’hôte commence à swapper, l’ARC rétrécit, le churn d’éviction augmente, et tout devient plus lent — même les lectures qui touchaient auparavant l’ARC.
Patron de symptômes : plus de fautes de page, CPU système plus élevé, taille ARC oscillante et pics de latence sous charge. On blâme souvent « le SSD », mais c’est généralement l’économie de la mémoire.
Mode de défaillance 2 : churn du cache et préchauffage qui ne finit jamais
Si votre working set change plus vite que L2ARC ne peut s’adapter, il devient un musée de blocs que vous utilisiez autrefois. Vous payez l’overhead d’alimentation et obtenez peu de hits. C’est courant dans :
- Grands scans séquentiels
- Fenêtres de sauvegarde qui touchent tout une fois
- Grosses requêtes analytiques qui parcourent linéairement des datasets
- Systèmes CI qui parcourent de nombreux artefacts uniques
Mode de défaillance 3 : amplification d’écriture du SSD et usure prématurée
Les périphériques L2ARC se font écrire dessus. Le cache est constamment rafraîchi. Sur certaines charges, le volume d’écriture peut être substantiel. Si vous utilisez un SSD grand public avec une endurance médiocre et un mauvais comportement d’écriture soutenue, vous pouvez finir avec :
- Dégradation des performances du SSD après l’épuisement du cache SLC
- GC en arrière-plan amplifiant la latence
- Usure qui se transforme en tapis roulant de remplacement
Mode de défaillance 4 : inversion de latence
Parfois, L2ARC peut introduire une « vitesse intermédiaire » plus lente que l’ARC mais qui consomme toujours CPU et ressources de mise en file. Si votre pool sous-jacent est déjà SSD/NVMe et que votre ARC est adéquat, les hits L2ARC peuvent être plus lents qu’une lecture bien comportée du pool — surtout si le périphérique L2ARC est partagé, occupé ou limité.
Mode de défaillance 5 : complexité opérationnelle non budgétée
Ajouter L2ARC signifie une autre classe de périphérique à surveiller, remplacer et planifier en capacité. Cela peut aussi compliquer l’analyse des performances : maintenant une lecture peut venir de l’ARC, du L2ARC ou du pool, et vous devez savoir quel chemin domine à 3 h du matin.
Trois mini-récits du monde de l’entreprise
Mini-récit n°1 : L’incident causé par une mauvaise hypothèse (« SSD cache = plus de vitesse »)
La configuration semblait raisonnable : un service de fichiers d’entreprise de taille moyenne sur un pool RAIDZ2 HDD, beaucoup de clients, et une plainte persistante que les lundis matins étaient lents. Quelqu’un a ajouté un grand SSD SATA comme L2ARC pendant le weekend. La file de tickets s’est calmée pendant environ une heure le lundi. Puis le tableau de bord de monitoring s’est allumé comme une machine à flipper.
La latence a monté. Le temps CPU système a augmenté. La machine a commencé à swapper. L’équipe applicative insistait « mais on a ajouté un SSD, ça doit être plus rapide ». Pendant ce temps, les graphiques de stockage montraient que le pool HDD n’était même pas saturé ; le problème était la pression mémoire et le churn de reclaim. Les en-têtes L2ARC avaient rongé la RAM, l’ARC avait rétréci, et les métadonnées chaudes de la charge ne tenaient plus. Le système a effectué plus d’I/O réel qu’avant, pas moins.
L’hypothèse erronée était subtile : ils croyaient que L2ARC remplacerait les lectures disque sans impacter quoi que ce soit d’autre. En réalité, L2ARC demandait de la RAM pour l’indexer, et cette RAM venait de l’ARC qui rendait le système tolérable. Quand l’OS a commencé à paginer, chaque « optimisation » est devenue une auto-DOS.
La correction fut ennuyeuse : retirer L2ARC, ajouter de la RAM, et traiter la vraie douleur — les traversées de répertoire riches en métadonnées pendant les scripts de connexion. Une tentative ultérieure a utilisé un périphérique L2ARC beaucoup plus petit et a adapté les attentes. Le vrai gain est finalement venu de la réduction de la tempête de métadonnées et du placement des fichiers les plus fréquemment accédés sur un stockage primaire plus rapide.
Mini-récit n°2 : L’optimisation qui a mal tourné (« Faisons-en plus pour mettre en cache »)
Un cluster de virtualisation avait un datastore sur ZFS. Les lectures étaient en rafales : tempêtes de boot, cycles de patch et des situations « tout le monde se connecte en même temps ». L2ARC a été installé et semblait légèrement utile. Puis quelqu’un a décidé de le régler de façon agressive — taux d’alimentation plus élevé, périphérique plus grand et « mettre plus de choses en cache ». Les graphiques semblaient super pendant la première fenêtre de test, ce qui est un signe qu’on s’apprête à apprendre quelque chose de coûteux.
Deux semaines plus tard, le support a commencé à voir des pics de latence intermittents. Pas constants, pas prévisibles. L’équipe hyperviseur accusait le réseau. Le réseau accusait le stockage. Le stockage accusait « inconnu ». Le seul signal constant était que le périphérique L2ARC atteignait parfois 100 % d’utilisation pendant les heures chargées, et la machine passait un temps surprenant dans des threads noyau.
Le retour de flamme venait de l’amplification d’écriture et de la contention. Nourrir le L2ARC plus intensément augmentait les écritures vers le périphérique cache, qui entraient en concurrence avec l’I/O légitime du pool sur le même canal de contrôleur. La GC interne du SSD a commencé à apparaître comme des jitter de latence. Le système n’était pas « plus lent » en moyenne ; il était moins stable, ce que les utilisateurs ressentent comme « c’est cassé ».
La solution finale : réduire les réglages, déplacer le périphérique cache vers un chemin moins contentieux, et privilégier la latence cohérente plutôt que le débit synthétique. L2ARC est resté, mais il a été traité comme un scalpel plutôt que comme un souffleur de feuilles.
Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (« Mesurer d’abord, changer une seule fois »)
Une équipe plateforme de données voulait L2ARC pour un service analytique. La demande était urgente — les plaintes de performance étaient fortes et quelqu’un avait déjà commandé des NVMe. Le SRE de garde a fait la chose la moins excitante possible : il a établi une baseline et a refusé de la sauter.
Ils ont capturé les stats ARC, la latence du pool et le p95 applicatif pendant la charge normale et pendant un job lourd connu. Ils ont aussi validé que la douleur provenait de lectures aléatoires sur des données plutôt froides, pas d’une saturation CPU ou d’une VM voisine bruyante. La baseline a montré quelque chose d’inattendu : l’ARC fonctionnait déjà bien, et la plupart des misses étaient de longues lectures séquentielles déclenchées par des scans batch. L2ARC mettrait en cache le scan d’hier et serait inutile aujourd’hui.
Au lieu de déployer L2ARC, ils ont utilisé le budget NVMe pour ajouter un vdev spécial pour métadonnées et petits blocs sur un pool test, et ils ont ajusté recordsize/compression pour la charge. Ce n’était pas glamour. Mais les plaintes « liste de répertoire lente » et « la première requête est affreuse » ont nettement diminué, et le système est devenu plus prévisible sous charge.
La pratique qui a sauvé la journée n’était pas un paramètre secret. C’était la discipline de mesurer le type réel de miss, puis choisir le mécanisme adapté. L2ARC est excellent quand le miss est « les données chaudes ne tiennent pas en RAM ». Il est médiocre quand le miss est « on scanne tout une fois ».
Méthode de diagnostic rapide
Voici l’ordre d’opérations « arriver dans l’incident ». Le but est d’identifier le goulot en quelques minutes, pas de gagner un débat sur Slack.
Étape 1 : est-ce de la pression mémoire ou le comportement du cache ?
- Vérifiez le swapping/paging et la stabilité de la taille de l’ARC.
- Si le système swappe, L2ARC est coupable jusqu’à preuve du contraire.
Étape 2 : les lectures proviennent-elles de l’ARC, du L2ARC ou du disque ?
- Vérifiez les ratios de hit ARC/L2ARC et les débits de lecture.
- Confirmez si L2ARC sert réellement des lectures (et n’est pas seulement écrit).
Étape 3 : le périphérique L2ARC est-il lui-même le goulot ?
- Cherchez une forte utilisation, un await élevé ou un throttling sur le périphérique cache.
- Surveillez les pics de latence cohérents avec la GC du SSD.
Étape 4 : le pool sous-jacent est-il lent pour une autre raison ?
- Vérifiez la latence I/O du pool et la profondeur de file.
- Cherchez fragmentation, disque en échec, ou problème de chemin de contrôleur.
Étape 5 : validez l’adéquation de la charge
- Si ce sont des scans séquentiels, L2ARC brillera rarement.
- Si ce sont des petites lectures aléatoires avec réutilisation, L2ARC peut être précieux.
Listes de vérification / plan étape par étape (avec commandes)
Ces tâches supposent un système Linux avec OpenZFS. Les commandes sont réalistes, mais certains fichiers/chemins varient selon la distro et la version de ZFS. L’objectif est des opérations répétables : observer, décider, changer, vérifier.
Tâche 1 : Vérifier la santé du pool avant d’accuser le cache
cr0x@server:~$ sudo zpool status -v
pool: tank
state: ONLINE
scan: scrub repaired 0B in 02:31:10 with 0 errors on Sun Dec 22 03:10:11 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
cache
nvme0n1 ONLINE 0 0 0
errors: No known data errorsInterprétation : Si le pool n’est pas sain, les symptômes de performance peuvent être des effets secondaires (retries, resilvering, erreurs de checksum). Réparez la santé d’abord.
Tâche 2 : Confirmer les périphériques L2ARC et leur attachement
cr0x@server:~$ sudo zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 72.5T 51.2T 21.3T - - 28% 70% 1.00x ONLINE -
raidz2 72.5T 51.2T 21.3T - - 28% 70%
sda - - - - - - -
sdb - - - - - - -
sdc - - - - - - -
sdd - - - - - - -
cache - - - - - - -
nvme0n1 1.8T 820G 1.0T - - - -Interprétation : Les périphériques L2ARC s’affichent sous cache. Si vous vouliez un cache en miroir et ne voyez qu’un seul périphérique, c’est un risque que vous n’avez peut‑être pas voulu prendre.
Tâche 3 : Capture d’un « quoi se passe maintenant » sur un écran
cr0x@server:~$ sudo zpool iostat -v tank 1 5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 51.2T 21.3T 1.20K 650 210M 95.4M
raidz2 51.2T 21.3T 1.20K 650 210M 95.4M
sda - - 310 160 54.0M 23.4M
sdb - - 280 170 48.9M 24.2M
sdc - - 320 150 56.1M 21.9M
sdd - - 290 170 51.0M 25.9M
cache - - 1.80K 0 290M 0
nvme0n1 - - 1.80K 0 290M 0
---------- ----- ----- ----- ----- ----- -----Interprétation : Si les lectures du périphérique cache sont élevées alors que les lectures du pool sont faibles, L2ARC sert activement. Si les lectures du cache sont proches de zéro, L2ARC n’aide pas (ou il est en train de chauffer, ou la charge ne réutilise pas).
Tâche 4 : Vérifier les statistiques principales ARC et L2ARC
cr0x@server:~$ grep -E "^(size|c_max|c_min|hits|misses|l2_hits|l2_misses)" /proc/spl/kstat/zfs/arcstats
size 4 68424495104
c_max 4 82463372032
c_min 4 10307921510
hits 4 12943923810
misses 4 1829381021
l2_hits 4 540128112
l2_misses 4 128925291Interprétation : L’ARC est ~68 GiB, max ~82 GiB. L2ARC a des hits ; calculez si ce taux est pertinent pour votre fenêtre de charge, pas pour la durée depuis le boot.
Tâche 5 : Calculer rapidement les ratios de hit (ARC et L2ARC)
cr0x@server:~$ python3 - <<'PY'
import re
stats={}
with open("/proc/spl/kstat/zfs/arcstats") as f:
for line in f:
parts=line.split()
if len(parts)==3:
stats[parts[0]]=int(parts[2])
hits=stats.get("hits",0); misses=stats.get("misses",0)
l2h=stats.get("l2_hits",0); l2m=stats.get("l2_misses",0)
arc_total=hits+misses
l2_total=l2h+l2m
print(f"ARC hit ratio: {hits/arc_total:.3f} ({hits}/{arc_total})" if arc_total else "ARC: n/a")
print(f"L2ARC hit ratio: {l2h/l2_total:.3f} ({l2h}/{l2_total})" if l2_total else "L2ARC: n/a")
PY
ARC hit ratio: 0.876 (12943923810/14773304831)
L2ARC hit ratio: 0.807 (540128112/669053403)Interprétation : Des ratios cumulés élevés peuvent tromper si la charge a changé. Reprenez des deltas sur 60–300 secondes pendant la période problématique.
Tâche 6 : Échantillonner les deltas ARC/L2ARC dans le temps (méthode incident réel)
cr0x@server:~$ for i in {1..5}; do
awk '($1=="hits"||$1=="misses"||$1=="l2_hits"||$1=="l2_misses"){print $1,$3}' /proc/spl/kstat/zfs/arcstats
sleep 2
done
hits 12943990112
misses 1829390029
l2_hits 540132882
l2_misses 128925900
hits 12944081201
misses 1829409110
l2_hits 540139551
l2_misses 128926499
hits 12944174500
misses 1829428800
l2_hits 540146002
l2_misses 128927101
hits 12944260110
misses 1829442301
l2_hits 540151774
l2_misses 128927690
hits 12944350990
misses 1829461988
l2_hits 540158441
l2_misses 128928291Interprétation : Calculez les taux de hit delta entre les échantillons. Si les deltas L2ARC montrent peu de hits mais beaucoup de misses, il n’est pas significatif dans le chemin de lecture.
Tâche 7 : Confirmer que vous ne swappez pas (le tueur silencieux)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 128Gi 97Gi 2.1Gi 1.2Gi 29Gi 24Gi
Swap: 8.0Gi 1.6Gi 6.4Gi
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
5 0 1652280 2211140 112000 23210400 12 28 3180 1200 5200 9800 12 18 55 15 0
6 1 1652280 1976200 111900 23180200 0 64 4020 990 5600 10100 10 22 50 18 0Interprétation : Un si/so non nul pendant la charge est un signal rouge. Si vous voyez un si/so soutenu, corrigez la pression mémoire avant d’ajuster L2ARC.
Tâche 8 : Identifier si le périphérique L2ARC est saturé
cr0x@server:~$ iostat -x 1 5
Linux 6.8.0 (server) 12/25/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
11.20 0.00 18.90 14.30 0.00 55.60
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 1800.0 297000.0 0.0 0.00 1.40 165.0 40.0 8000.0 3.10 2.80 96.00
sda 300.0 54000.0 2.0 0.60 10.20 180.0 160.0 24000.0 9.50 5.10 88.00Interprétation : Si le périphérique cache est à ~100 % d’utilisation avec un await croissant, il peut devenir le goulot — surtout si les hits L2ARC dominent.
Tâche 9 : Inspecter les kstats L2ARC pour la taille et le comportement d’alimentation
cr0x@server:~$ grep -E "^(l2_size|l2_asize|l2_hdr_size|l2_write_bytes|l2_read_bytes|l2_writes_sent|l2_evicts)" /proc/spl/kstat/zfs/arcstats
l2_size 4 912345678912
l2_asize 4 1000204886016
l2_hdr_size 4 2147483648
l2_write_bytes 4 18765432109876
l2_read_bytes 4 7654321098765
l2_writes_sent 4 987654321
l2_evicts 4 123456789Interprétation : l2_hdr_size est l’overhead RAM pour la tenue du L2ARC. S’il fait plusieurs Gio et que vous êtes serré en mémoire, votre « cache » peut vous louer de la RAM à prix fort.
Tâche 10 : Ajouter un périphérique L2ARC en sécurité (et vérifier)
cr0x@server:~$ sudo zpool add tank cache /dev/disk/by-id/nvme-SAMSUNG_MZQLB1T9HAJR-00007_S4XXXXXXXXX
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
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
cache
nvme-SAMSUNG_MZQLB1T9HAJR-00007_S4XXXXXXXXX ONLINE 0 0 0Interprétation : Utilisez toujours des chemins de périphérique stables (by-id). Après ajout, vous devez toujours valider qu’il sert des lectures et ne pousse pas l’hôte en pression mémoire.
Tâche 11 : Retirer un périphérique L2ARC pendant le dépannage
cr0x@server:~$ sudo zpool remove tank nvme0n1
cr0x@server:~$ sudo zpool status tank
pool: tank
state: ONLINE
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
errors: No known data errorsInterprétation : Retirer L2ARC est habituellement sûr car c’est un cache. Le vrai risque est la chute de performance si vous en tiriez effectivement bénéfice. Utilisez-le comme levier de test A/B.
Tâche 12 : Distinguer L2ARC du SLOG (les gens les confondent constamment)
cr0x@server:~$ sudo zpool status -v tank
pool: tank
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme1n1 ONLINE 0 0 0
nvme2n1 ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
nvme3n1 ONLINE 0 0 0
nvme4n1 ONLINE 0 0 0Interprétation : Les périphériques sous logs sont des SLOG (accélération des écritures synchrones). Les périphériques sous cache sont L2ARC (cache de lecture). Problèmes différents, corrections différentes.
Tâche 13 : Surveiller le comportement en lecture par dataset (compression, recordsize)
cr0x@server:~$ sudo zfs get -o name,property,value,source compression,recordsize,primarycache,secondarycache tank/vmstore
NAME PROPERTY VALUE SOURCE
tank/vmstore compression lz4 local
tank/vmstore recordsize 128K local
tank/vmstore primarycache all default
tank/vmstore secondarycache all defaultInterprétation : Si secondarycache=none, L2ARC ne mettra pas en cache ce dataset. Cela peut être intentionnel (prévenir la pollution du cache) ou accidentel (pourquoi L2ARC est inutile ?).
Tâche 14 : Exclure les datasets lourds en scan du L2ARC pour réduire le churn
cr0x@server:~$ sudo zfs set secondarycache=none tank/backups
cr0x@server:~$ sudo zfs get secondarycache tank/backups
NAME PROPERTY VALUE SOURCE
tank/backups secondarycache none localInterprétation : C’est un des réglages à plus fort ROI : empêcher les sauvegardes/scans d’inonder le L2ARC avec des lectures one-shot.
Tâche 15 : Confirmer le comportement TRIM pour les SSD cache
cr0x@server:~$ sudo zpool get autotrim tank
NAME PROPERTY VALUE SOURCE
tank autotrim on localInterprétation : TRIM peut aider les performances soutenues des SSD. L’activer dépend de vos SSD et de la version kernel/ZFS, mais « désactivé pour toujours » est souvent une inertie héritée.
Tâche 16 : Créer un rapide benchmark avant/après qui ne ment pas trop
cr0x@server:~$ sudo bash -c 'echo 3 > /proc/sys/vm/drop_caches'
cr0x@server:~$ sudo zpool iostat -v tank 1 3
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
tank 51.2T 21.3T 900 10 180M 1.2M
cache - - 20 0 2.0M 0
nvme0n1 - - 20 0 2.0M 0Interprétation : Vider les caches est disruptif et pas « réel », mais cela peut démontrer si votre charge touche le L2ARC. Utilisez-le prudemment, idéalement sur un système de test ou pendant une fenêtre contrôlée.
Erreurs fréquentes : symptômes spécifiques et corrections
Erreur 1 : Utiliser L2ARC pour résoudre un problème d’écriture
Symptôme : Écritures synchrones lentes, latence de commit de base de données, NFS avec sync qui souffre, mais les lectures vont bien.
Correction : L2ARC n’aidera pas. Examinez le SLOG, les réglages sync, la latence des dispositifs de log, et les patterns d’écriture applicatifs. Confirmez avec zpool iostat et les métriques de charge.
Erreur 2 : Ajouter un énorme L2ARC sur un hôte limité en mémoire
Symptôme : Après l’ajout de L2ARC, la taille ARC chute, l’utilisation du swap augmente, le CPU système augmente, la latence empire.
Correction : Retirez ou réduisez L2ARC. Ajoutez de la RAM. Vérifiez l2_hdr_size et le paging (vmstat). L2ARC n’est pas « de la capacité gratuite ».
Erreur 3 : Mettre en cache des datasets lourds en scan et empoisonner le cache
Symptôme : Les écritures L2ARC sont élevées, le taux de hit L2ARC est faible, et la performance se dégrade pendant les fenêtres de sauvegarde/scan.
Correction : Mettez secondarycache=none sur les datasets lourds en scan (backups, scratch analytique, sorties ETL one-pass). Gardez L2ARC pour les lectures réutilisables.
Erreur 4 : Choisir le mauvais SSD (drive grand public, mauvais écriture soutenue, firmware médiocre)
Symptôme : Le périphérique cache montre des pics de latence périodiques, les performances sont « bien puis affreuses », les indicateurs d’usure SMART augmentent vite.
Correction : Utilisez des SSD d’entreprise avec une QoS prévisible et une endurance adéquate. Surveillez l’usure SMART. Envisagez de surprovisionner et d’activer TRIM.
Erreur 5 : S’attendre à une amélioration instantanée juste après l’activation
Symptôme : « On a ajouté L2ARC et rien n’a changé. »
Correction : L2ARC met du temps à chauffer. Validez avec des échantillons delta des hits/misses pendant la charge. Si le working set n’est pas réutilisé, il peut ne jamais aider.
Erreur 6 : L2ARC sur des pools déjà rapides tout-NVMe sans goulot clair
Symptôme : Aucun gain mesurable, parfois une latence légèrement pire à cause de l’overhead.
Correction : Privilégiez plus de RAM (plus grand ARC) ou l’optimisation de la charge/dataset. Sur des pools très rapides, la couche supplémentaire L2ARC peut être une complexité inutile.
FAQ
1) L2ARC met-il en cache les écritures ?
Non. L2ARC est un cache de lecture. Les écritures vont dans le pool (et éventuellement dans le ZIL/SLOG pour la sémantique sync). Si votre problème est la latence d’écriture, cherchez ailleurs.
2) Pourquoi ajouter un SSD cache peut-il empirer les performances ?
Parce que L2ARC a un coût : il consomme de la RAM pour les métadonnées du cache, du CPU pour le gérer et de la bande passante I/O pour le peupler. Si ces coûts dépassent les lectures disque économisées — ou déclenchent du swapping — les performances chutent.
3) Quelle taille pour mon L2ARC ?
Assez grand pour contenir la partie « tiède mais pas la plus chaude » de votre working set, mais pas si grand que l’overhead des métadonnées grignote votre budget RAM. En production, la bonne taille est généralement contrainte par la RAM d’abord, pas par la capacité SSD.
4) Comment savoir si L2ARC est vraiment utilisé ?
Regardez zpool iostat -v pour les lectures du périphérique cache et vérifiez les deltas l2_hits dans /proc/spl/kstat/zfs/arcstats pendant la fenêtre de charge. Les statistiques cumulées depuis le boot peuvent induire en erreur.
5) Dois-je mettre les périphériques L2ARC en miroir ?
Généralement pas nécessaire car c’est un cache et il peut être reconstruit. Mais si sa perte entraîne une dégradation de performance inacceptable et que le temps de remplacement compte, le mirroring peut être une décision métier. Opérationnellement : considérez‑le comme une redondance de performance, pas de données.
6) Le L2ARC persistant existe-t-il ?
Sur certaines versions et plateformes OpenZFS, oui — des fonctionnalités de L2ARC persistant existent. Mais vous devez vérifier le comportement sur votre pile exacte. Ne supposez pas « ça persiste » avant d’avoir testé un reboot et confirmé le comportement de préchauffage.
7) Quelle est la différence entre L2ARC et un vdev spécial ?
L2ARC est une couche de cache pour les lectures. Un vdev spécial fait partie du pool et peut stocker de façon permanente des métadonnées (et éventuellement de petits blocs) sur du média plus rapide. Les vdevs spéciaux peuvent changer la donne pour les charges riches en métadonnées, mais ils ne sont pas jetables : si vous les perdez sans redondance, vous pouvez perdre le pool.
8) Puis-je utiliser L2ARC sur un système avec peu de RAM ?
Vous pouvez, mais vous ne devriez probablement pas sauf si le L2ARC est petit et validé avec soin. Le chemin rapide vers le regret est « ajouter un gros L2ARC » sur un hôte déjà proche des limites mémoire.
9) Dois-je désactiver L2ARC pour les sauvegardes ?
Souvent oui. Les sauvegardes font fréquemment de grandes lectures séquentielles avec peu de réutilisation. Mettre secondarycache=none pour les datasets de sauvegarde est une pratique courante pour prévenir la pollution du cache.
10) Quelles métriques importent le plus pour juger L2ARC ?
La latence en queue (p95/p99) côté application, les deltas hits/misses ARC/L2ARC pendant la charge, la latence/IOPS de lecture du pool, l’utilisation/latence du périphérique cache et les indicateurs de pression mémoire (swap, comportement de reclaim).
Conclusion
L2ARC est un outil puissant avec une mission très spécifique : sauver des charges orientées lecture dont le working set ne tient pas en RAM, sans payer l’intégralité de la pénalité du stockage primaire lent. Lorsqu’il correspond à la charge, il peut lisser la latence en queue et réduire le thrash disque d’une manière perceptible pour les utilisateurs.
Mais L2ARC n’est pas « la vitesse SSD gratuite ». C’est un cache qui coûte de la RAM, du CPU et de l’attention opérationnelle. Traitez‑le comme une infrastructure de production : mesurez d’abord, ajoutez‑le délibérément, protégez‑le de la pollution par les scans, et soyez prêts à le retirer comme expérience contrôlée. Si vous faites cela, L2ARC se comportera comme un allié. Si vous ne le faites pas, il se comportera comme toutes les autres « optimisations rapides » : utile jusqu’au moment où il devient l’incident.