Guide pratique d’optimisation des performances ZFS sur Linux

Introduction

ZFS est un système de fichiers moderne offrant intégrité des données, compression transparente et snapshots. Cependant, ses performances dépendent de la configuration du pool, des paramètres de datasets et du matériel sous-jacent. Ce guide couvre les étapes pour mesurer, identifier et améliorer les performances en restant prudent sur la sécurité des données.

Mesurer la performance

Avant de modifier quoi que ce soit, il faut collecter des mesures de base. Utilisez les outils suivants pour obtenir des indicateurs clairs :

• Surveillance de la charge et des I/O : iostat, arcstat.
• État SMART des disques : smartctl.
• Benchmarks d’E/S : fio pour tests séquentiels et aléatoires.
• Gestion des pools : zpool et zfs pour vérification d’état et propriétés.

Procédez ainsi :

1. Collectez une baseline pendant la charge normale avec iostat -x et arcstat.
2. Vérifiez les erreurs SMART avec smartctl -a.
3. Exécutez des tests contrôlés avec fio pour mesurer latence et débit.

Paramètres ZFS à vérifier

Les propriétés d’un dataset influencent fortement les performances. Voici celles à prioriser :

• recordsize — Ajuster pour correspondre au profil d’accès (ex. 128K pour fichiers séquentiels, 8K pour bases de données).
• volblocksize — Pertinent pour les volumes block-based ; doit correspondre aux I/O applicatives.
• atime — Désactivez-le si l’accès aux atimes n’est pas requis pour réduire les écritures.
• compression — Activez si vos données compressent bien ; peut améliorer débit et réduire IOPS.
• primarycache / secondarycache — Ajustez selon la taille de votre ARC et la présence d’un L2ARC.
• logbias — Valeur « throughput » ou « latency » selon les priorités d’écriture synchrone.
• ashift — Doit correspondre à l’alignement physique des disques (souvent 12 pour 4K).

Réglages système et matériel

Au-delà des options ZFS, le sous-système matériel et le noyau influencent les performances :

• Vérifiez que les contrôleurs RAID/HBA sont en mode approprié (pas d’écriture cache risquée).
• Assurez-vous que le réglage I/O scheduler est adapté (ex. mq-deadline ou none pour NVMe).
• Dimensionnez l’ARC selon la mémoire disponible ; surveillez avec arcstat.
• Utilisez un L2ARC sur support rapide si vous avez des lectures fréquentes hors ARC.

Procédure de benchmark recommandée

Exemple de séquence pour un benchmark reproductible :

1. Établissez une baseline en charge normale (24 à 48 heures si possible).
2. Effectuez un test fio contrôlé : charges séquentielles et aléatoires, tailles d’I/O adaptées à l’application.
3. Changez une seule propriété ZFS (par ex. recordsize), réexécutez les mêmes scénarios fio et comparez.
4. Documentez latence 99ème percentile, IOPS, et débit ; ne vous fiez pas seulement aux moyennes.

Remarque : pour les workloads sensibles, privilégiez fio avec des profils réalistes plutôt que des tests synthétiques trop simples.

Conclusion

L’optimisation ZFS est avant tout itérative : mesurer, ajuster une variable à la fois, et re-mesurer. Les gains les plus significatifs proviennent souvent d’une meilleure adéquation entre la configuration de dataset (recordsize, volblocksize), les politiques de cache et le profil applicatif. N’oubliez pas que la résilience et l’intégrité des données restent la priorité.

FAQ

Q : Dois-je toujours désactiver atime ?

R : Si vous n’avez pas besoin des accès temps, désactiver atime réduit les écritures. Toutefois, certaines applications peuvent en dépendre, testez avant en production.

Q : L’activation de la compression réduit-elle la CPU ?

R : La compression peut augmenter l’utilisation CPU, mais si les données sont compressibles, elle réduit les IOPS et améliore souvent le débit global.

Q : Comment choisir recordsize ?

R : Choisissez recordsize en fonction du type d’accès : grands fichiers séquentiels -> grands recordsize ; bases de données -> petits recordsize. Mesurez l’impact avec fio.